Probes branch: nodeIds inferred by extractTracePoints sometimes don't match actual nodeIds inserted into code

[rklancer]

Investigating again why test/test-vals.js fails, I discovered that extractTracePoints seems to do its own AST walk to document the nodeIds of trace points that are actually inserted into the code during a later AST walk (is that right?).

I found that the nodeId scripts/vals.js-probe-15-33-15-33 was inferred for the return 22; statement in test/scripts/vals.js, but the later AST walk actually inserts a probe trace point with nodeId scripts/vals.js-probe-15-31-15-31.

I'm also (perhaps this should be the real issue!) hoping that Theseus will be able to make use of nodeIds that report the start and end of the actual expression being probed rather than using the location of the end of the line containing the expression for both the start and end--because this is the value I'd like to use.

Cheers and HTH, --Richard

[alltom]

Thanks for looking into this and forcing me to page all of this stuff into my head again. :) The probes branches are still half-baked and I agree with your suggestion: probes should report the actual start and end of the expression.

At the moment fondue reports the position where Theseus should insert the visualization of the probe value, which was convenient for the implementation of that demo, but not a good choice in general. The location where the value should be visualized can be derived from the range of the expression anyway.

I think I might hack on this a little now...

[alltom]

Just pushed a few commits so that now the probe nodes are generated (and tested) correctly, though the calls to traceProbeValue are no longer generated with the right arguments. Time for sleep now. 😴