In case you missed it, I've released a new tool called Heatfiler. It's
a profiler and code coverage tool for JS (of course) in JS (of
course). It works completely on the client and has no dependencies
(server or otherwise).
I built it using ZeParser to do the rewriting. It is count-based (not
time based, though it could be when using the micro time spec) and
gives you a real-time updating heatmap. You can run the code in the
page of the heatmap or the two separate in tabs. You can also pretty
easily integrate the profiler in an existing project.
Feedback is welcome. Note that this is a two day effort. It's not my
cleanest code ever. And I don't intend (right now anyways) to improve
the tool, short of bug fixing.
If anyone can think of a syntax case that would fail in the rewrite
rules (not covered by ignored tests), please let me know (or just file
a ticket on github). I think I've covered my bases pretty well, but I
wouldn't be surprised if I let a case through :)
What I'd like to see to happen is the converging of a standardized way
to inject instrumentation to the code. This is the heart of all
JavaScript-based coverage. Just like syntax tree (AST) format,
interoperability is easy if everybody follows (more or less) the same
strategy instead of N different and incompatible ways.
Having a pure instrumentation tool only is still very useful. In
particular, if there is a possibility to instrument specific part of
the code only. For example, some testing tool can run the instrumented
code as part of its testing procedure and for the performance reason
it might not start by instrumenting everything.
Claus, probably it's time to evangelize such a standardized format (at
minimum, towards reaching "de-facto") for code instrumentation?
I'm fascinated by the heatmap. If it supported source map generation, then
something like the Web Indpector (or later Firefox and Firebug) could give
a heatmap back on the original source.
On Tuesday, August 28, 2012, Peter van der Zee wrote:
> In case you missed it, I've released a new tool called Heatfiler. It's
> a profiler and code coverage tool for JS (of course) in JS (of
> course). It works completely on the client and has no dependencies
> (server or otherwise).
> I built it using ZeParser to do the rewriting. It is count-based (not
> time based, though it could be when using the micro time spec) and
> gives you a real-time updating heatmap. You can run the code in the
> page of the heatmap or the two separate in tabs. You can also pretty
> easily integrate the profiler in an existing project.
> Feedback is welcome. Note that this is a two day effort. It's not my
> cleanest code ever. And I don't intend (right now anyways) to improve
> the tool, short of bug fixing.
> If anyone can think of a syntax case that would fail in the rewrite
> rules (not covered by ignored tests), please let me know (or just file
> a ticket on github). I think I've covered my bases pretty well, but I
> wouldn't be surprised if I let a case through :)
> In case you missed it, I've released a new tool called Heatfiler. It's
> a profiler and code coverage tool for JS (of course) in JS (of
> course). It works completely on the client and has no dependencies
> (server or otherwise).
> I built it using ZeParser to do the rewriting. It is count-based (not
> time based, though it could be when using the micro time spec) and
> gives you a real-time updating heatmap. You can run the code in the
> page of the heatmap or the two separate in tabs. You can also pretty
> easily integrate the profiler in an existing project.
> Feedback is welcome. Note that this is a two day effort. It's not my
> cleanest code ever. And I don't intend (right now anyways) to improve
> the tool, short of bug fixing.
> If anyone can think of a syntax case that would fail in the rewrite
> rules (not covered by ignored tests), please let me know (or just file
> a ticket on github). I think I've covered my bases pretty well, but I
> wouldn't be surprised if I let a case through :)
On Tue, Aug 28, 2012 at 9:07 AM, Anton Kovalyov <an...@kovalyov.net> wrote:
> Heatmap looks awesome. We (JSHint) use Coveraje as our code coverage tool
> and I'd love to see similar heatmap there.
> Anton
> On 28 August 2012 07:18, Peter van der Zee <qfo...@gmail.com> wrote:
>> Hi all,
>> In case you missed it, I've released a new tool called Heatfiler. It's
>> a profiler and code coverage tool for JS (of course) in JS (of
>> course). It works completely on the client and has no dependencies
>> (server or otherwise).
>> I built it using ZeParser to do the rewriting. It is count-based (not
>> time based, though it could be when using the micro time spec) and
>> gives you a real-time updating heatmap. You can run the code in the
>> page of the heatmap or the two separate in tabs. You can also pretty
>> easily integrate the profiler in an existing project.
>> Feedback is welcome. Note that this is a two day effort. It's not my
>> cleanest code ever. And I don't intend (right now anyways) to improve
>> the tool, short of bug fixing.
>> If anyone can think of a syntax case that would fail in the rewrite
>> rules (not covered by ignored tests), please let me know (or just file
>> a ticket on github). I think I've covered my bases pretty well, but I
>> wouldn't be surprised if I let a case through :)
On Tue, Aug 28, 2012 at 7:01 PM, Mark Hahn <m...@hahnca.com> wrote:
> Looks awesome.
> FYI: On latest dev version of chrome I'm getting an unreadable mess for the
> result.
Can you tell what might be going on? Maybe post a screenshot? I'm not
doing too much weird stuff, especially in the heatmap itself. It's
just a <pre> with some <span>s which have background colors. So I'm
not sure why that would screw up.
It hooks into require.extensions and makes use of the undocumented
module._compile. I was ensured that this was the only way and that the
only alternative was to have people manually save converted source and
run it like that. This was actually "strongly encouraged". So F that.
I used _compile and I used it well.
Also fixed a silly bug where `(function(){}())` would cause an error
(because I was branching at `function` for either a function or an
expression start, but in this case it's both so code that was relying
on a span for the expression failed to find it).
> What I'd like to see to happen is the converging of a standardized way
> to inject instrumentation to the code. This is the heart of all
> JavaScript-based coverage. Just like syntax tree (AST) format,
> interoperability is easy if everybody follows (more or less) the same
> strategy instead of N different and incompatible ways.
> ..
> Claus, probably it's time to evangelize such a standardized format (at
> minimum, towards reaching "de-facto") for code instrumentation?
I'm always tempted by standard suggestions, in that they reduce
insecurity (which platform to invest work in) and encourage reuse:-)
However, given the experience with trying for standardized ASTs,
parsers, traversals, or transformations, I don't feel that is realistic
in Javascript. Those who invest their time seem to like having their
own solutions, even if it means that some problems have noone
working on them while others attract two or more coders.
Don't want to discourage you, though!-) Code instrumentation
is one of those areas where there is a common subset of tools
with a variety of useful applications.
