[Pharo-project] code coverage
Hi All, anyone have any bytecode-to-bytecode transformation tools for doing basic-block resolution coverage? -- best, Eliot
On 21 February 2013 19:52, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
anyone have any bytecode-to-bytecode transformation tools for doing basic-block resolution coverage?
Is it possible that Jejak [1] might vaguely fit this bill? It's a tracing tool, but maybe one could hack something on the side to turn it into a coverage tool? Certainly I've wanted a fine resolution (branch/block level) coverage tool for a long time. frank [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html
On Feb 21, 2013, at 9:52 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 21 February 2013 19:52, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
anyone have any bytecode-to-bytecode transformation tools for doing basic-block resolution coverage?
Is it possible that Jejak [1] might vaguely fit this bill? It's a tracing tool, but maybe one could hack something on the side to turn it into a coverage tool?
Certainly I've wanted a fine resolution (branch/block level) coverage tool for a long time.
In Pharo 3.0 we will add Opal to the release (with the old Compiler to be an unload able package, to be killed as the first action in 4.0) This will allow *a lot* of very very interesting things to be done. Imagine this combined with -> a Parser that can parse code with syntax errors (in Pharo 2.0) -> a new ClassBuilder -> The first class Slots replacing instance variables (see the OOPLSA Paper) -> the new Debugger Model and UI -> the new text model It (slowly) start to get interesting! :-) Marcus
Le 22/02/2013 07:23, Marcus Denker a écrit :
On Feb 21, 2013, at 9:52 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 21 February 2013 19:52, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
anyone have any bytecode-to-bytecode transformation tools for doing basic-block resolution coverage?
Is it possible that Jejak [1] might vaguely fit this bill? It's a tracing tool, but maybe one could hack something on the side to turn it into a coverage tool?
Certainly I've wanted a fine resolution (branch/block level) coverage tool for a long time.
In Pharo 3.0 we will add Opal to the release (with the old Compiler to be an unload able package, to be killed as the first action in 4.0)
Yes, yes, I want Opal :)
This will allow *a lot* of very very interesting things to be done.
From your doc, I think there are many hooks to explore and change the generated bytecode with Opal, am I right ? Thierry
Imagine this combined with -> a Parser that can parse code with syntax errors (in Pharo 2.0) -> a new ClassBuilder -> The first class Slots replacing instance variables (see the OOPLSA Paper) -> the new Debugger Model and UI -> the new text model
It (slowly) start to get interesting! :-)
Marcus
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On Feb 22, 2013, at 9:16 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 22/02/2013 07:23, Marcus Denker a écrit :
On Feb 21, 2013, at 9:52 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 21 February 2013 19:52, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
anyone have any bytecode-to-bytecode transformation tools for doing basic-block resolution coverage?
Is it possible that Jejak [1] might vaguely fit this bill? It's a tracing tool, but maybe one could hack something on the side to turn it into a coverage tool?
Certainly I've wanted a fine resolution (branch/block level) coverage tool for a long time.
In Pharo 3.0 we will add Opal to the release (with the old Compiler to be an unload able package, to be killed as the first action in 4.0)
Yes, yes, I want Opal :)
This will allow *a lot* of very very interesting things to be done.
From your doc, I think there are many hooks to explore and change the generated bytecode with Opal, am I right ?
Yes, it has a control flow graph of byte code instruction objects. These can be easily explored and there an API for adding / removing nodes. We should get the high-level byte code transformation API working again, too. http://scg.unibe.ch/archive/papers/Denk06aRuntimeByteCodeESUGJournal.pdf But in general, I am not that of a fan of byteocode anymore. It's just too low level as a structural representation of code. Marcus
Le 21/02/2013 21:52, Frank Shearar a écrit :
On 21 February 2013 19:52, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
anyone have any bytecode-to-bytecode transformation tools for doing basic-block resolution coverage?
Is it possible that Jejak [1] might vaguely fit this bill? It's a tracing tool, but maybe one could hack something on the side to turn it into a coverage tool?
Yes, it could, but remember that it works at the source code level and that as a consequence you need to plan a bit your probes so that they match the expected bytecode generation (i.e. beware of optimisations). On the plus side, it's totally compiler-independent.
Certainly I've wanted a fine resolution (branch/block level) coverage tool for a long time.
That can be done in a short time... Thierry
frank
[1] http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On Feb 21, 2013, at 8:52 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
anyone have any bytecode-to-bytecode transformation tools for doing basic-block resolution coverage?
Opal can represent the byte code in a control flow graph. This was used for ByteSurgeon, we should revisit that as soon as the Compiler is in the image. Of course for basic blocks, one need to take care about where to add at the start of the block. Lots byte codes (creating tempVectors, pushing the nil for the tempsâ¦) that have no semantic meaning in Smalltalk. In the long term I would like to get rid of byte code as a visible artefact for reflection, though. It's just too low level. Especially the current byte code set is very low level. You can not even tell if a temp is a real temp without resorting to the full compiler chain. (Which shows that it is an execution level artefact, not a reflective one). I think moving the reflective model to something closer to the language is the way to go in the long term. Marcus
participants (4)
-
Eliot Miranda -
Frank Shearar -
Goubier Thierry -
Marcus Denker