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.clem...@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.ber...@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.clem...@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.shea...@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.clem...@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.shea...@gmail.com>
> > >>
> > >> On 6 April 2013 07:47, Stéphane Ducasse <stephane.duca...@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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
>
> --
> Clément Béra
> Mate Virtual Machine Engineer
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
