What I had in mind, is something like:

-=-=-=-=-=-=-=-=-=-=

myMethodWithBranch

self foo.

v�

ifTrue: [ ... ]

ifFalse: [ ... ]

-=-=-=-=-=-=-=-=-=-=

-=-=-=-=-=-=-=-=-=-=

myMethodWithBranch
self foo.

v�
ifTrue: [ self checkPoint: 1. ... ]
ifFalse: [ self checkPoint: 2. ... ].

self checkPoint: 3.

-=-=-=-=-=-=-=-=-=-=

All these checkpoint will be inserted by manipulating the bytecode. You can then optimize a bit by removing checkpoints that have been reached.

The method #checkPoint: could then use some attributes to the CompiledMethod.

This is a common technique when (i) the VM does not give you what you need and (ii) when you do not want to change the VM.

This is something I wanted to do for year in Hapao...�

Alexandre

On Apr 7, 2013, at 3:21 AM, Cl�ment Bera <bera.clement@gmail.com> wrote:

I don't know. The main problem is that the AST-interpreter is not fast enough. The best solution for speed would be to improve it as they do in this paper :�http://dl.acm.org/citation.cfm?id=2384587�(their ast-interpreter is faster than a byte code interpreter).

Another solution would be to execute some method with the vm and other one with the ast-interpreter, but it is quite some work.


2013/4/7 Alexandre Bergel�<alexandre.bergel@me.com>
Would it be possible to annotate the method with some checkpoints within the method? This should be fast enough I guess.

Alexandre


On Apr 6, 2013, at 10:35 AM, Cl�ment Bera <bera.clement@gmail.com> wrote:

> 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

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel �http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

--�
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel �http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.