This is exactly that. The tree coverage tool is a subclass of AST-interpreter, which adding to the interpretation marks the nodes. And then I use this marking to color the source code. And I use as you said RB ast.

This is why I implemented it in a few hours, I had already an AST-interpreter, so I've just created a quick subclass and a spec UI.

2013/4/6 Frank Shearar <frank.shearar@gmail.com>

So if you don't mind me being very loose with terminology, you
interpret (RB) ASTs, and the act of interpreting marks the nodes in
these ASTs, which you can then use to colour source?

frank

On 6 April 2013 11:00, Cl�ment Bera <bera.clement@gmail.com> wrote:
> Actually, it is quite different than Jejak.
>
> Implementation wise, Jejak used Opal so I guess it relies on bytecode
> modification to do its analysis where my tool relies on ast annotations.
>
> This implies some difference in features. It seems that Jejak record all
> calls, all values and all assignments in a method (which is byte code level
> feature), whereas I record for each ast node if it was interpreted or not
> (which is ast level feature). I guess there would be a little difference in
> the use cases.
>
>
> 2013/4/6 Frank Shearar <frank.shearar@gmail.com>
>>
>> On 6 April 2013 07:47, St�phane Ducasse <stephane.ducasse@inria.fr> wrote:
>>>
>>> Clement built in a couple of hours the following nice branch
>>> analysecoverage tools :)
>>> It is dead slow but cool.
>>
>>
>> By "branch coverage tool" do you mean Jejak?
>>
>> frank
>>
>>
>
>
>
> --
> Cl�ment B�ra
> Mate Virtual Machine Engineer
> B�timent B 40, avenue Halley 59650 Villeneuve d'Ascq

--
Cl�ment B�ra

Mate Virtual Machine Engineer

B�timent B 40, avenue Halley 59650�Villeneuve d'Ascq