TM: In debug builds, expose whether we're on trace or not (tracemonkey.onTrace)

RESOLVED FIXED

Status

()

RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: jorendorff, Assigned: jorendorff)

Tracking

Other Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 attachment)

(Assignee)

Description

9 years ago
The problem with such a feature, of course, is that people are tempted to use the boolean value as a branching condition:

  for (var x = 0; x < 20; x++) {
      if (tracemonkey.onTrace)      // d'oh
          print("on trace");
  }

This could end up being really misleading if you don't recognize what's going on. When onTrace is true, you'll end up taking a different path through the loop--which forces you off trace.

On the other hand, suppose you have a large test case and you want to know whether a particular loop is staying on trace or not. You could just add:
  print("onTrace: " + tracemonkey.onTrace);
and that will tell you the answer without shunting you onto the wrong track. Or similarly, you could add this:

  for (...) {
      ...
      wasOnTrace = tracemonkey.onTrace;  // sample without branching
      ...
  }
  print("last loop was on trace?: " + wasOnTrace);

You have to be careful, but I think the pros outweigh the cons.
Would tracemonkey.storeOnTrace("nameOfGlobal") be less hazardous?
(Assignee)

Comment 2

9 years ago
Created attachment 437061 [details] [diff] [review]
v1
Assignee: general → jorendorff
Attachment #437061 - Flags: review?(gal)

Updated

9 years ago
Attachment #437061 - Flags: review?(gal) → review+
(Assignee)

Comment 3

9 years ago
(In reply to comment #1)
> Would tracemonkey.storeOnTrace("nameOfGlobal") be less hazardous?

Sounds like a trigger lock. Theoretically, yeah, it becomes harder to get the footgun to fire. But there's nothing preventing the user from thinking "man, this api sucks--oh well" and then going straight on and doing whatever dumb thing they were going to do.

I also thought about taking the "usability through obscurity" approach and calling it tracemonkey.bananas or something.

Both remedies seem kind of out of proportion to the risk of confusion here--as I estimate it, anyway.
You could also make it an outparam-like thing, that set a property on a passed-in object.  I too think the risk of confusion's small enough to not worry about the problem, tho.
(Assignee)

Comment 5

9 years ago
http://hg.mozilla.org/tracemonkey/rev/db47682c74aa
Whiteboard: fixed-in-tracemonkey

Comment 6

9 years ago
http://hg.mozilla.org/mozilla-central/rev/db47682c74aa
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.