949723 - Should show code coverage in the editor while executing

Status: NEW

(DevTools :: Debugger, enhancement, P5)

Description

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Not necessarily dependent on bug 929349, but related in that we would use the tracer actor here as well.

Because of the sheer number of traces we get firehosed with from the server, I think it makes sense to just pass them off to a worker immediately. That worker can then run a reduce on the trace data and reply with the set of functions that have been called so that the debugger controller can use |DebuggerController.Parser| and |DebuggerView.editor.markText| to highlight functions that have been executed.

This could be a good project for a contributor who knows their way around the debugger and wants something in depth / a little bigger.

Here is a slightly simplified diagram:

============================================================================

+--------------------------+
| Tracer Actor (on Server) |
+--------------------------+
        |
        |
  { trace logs }
        |
        |
        V
+---------------------------+              +------------------------------+
| DebuggerController.Traces |------------->| DebuggerView.editor.markText |
+---------------------------+              +------------------------------+
       |          ^
       |          |
 { trace logs }   |
       |          |
       |    [Set of executed functions]
       V          |
+----------------------+
| Code Coverage Worker |
+----------------------+

============================================================================

Finally, we also need to be sure to handle the toggling of pretty printing and make sure that our highlighted text is updated as well.

Comment 1

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Actually I guess this does depend on bug 929349 because we will need |DebuggerController.Tracer| here.

Comment 2

[Victor Porof [:vporof][:vp]]

Dat ascii 

Comment 3

[Hubert B Manilla]

Would be digging into this.

Comment 4

[Hubert B Manilla]

...if its ok?

Comment 5

[Eddy Bruel [:ejpbruel]]

(In reply to Hubert B Manilla from comment #4)
> ...if its ok?

Sorry for not responding to your comment earlier Hubert. Mozillians get a huge amount of bugmail, so sometimes messages slip through the cracks.

I'd love to see this happen, so if you are still interested in digging into this, I'd be happy to help out. Either write a comment in the bug or send me an e-mail, and we'll get you up to speed!

Comment 6

[Hubert B Manilla]

Hey Nick,
NP. i'm still really keen on digging into this.
It looks like a couple of things have changed and/or relating to the design and stuff.
Would love to get up to speed.

Thanks

Comment 7

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

I'm not really on top of the new work going on for code coverage. Perhaps jlongster is a better point of contact.

Comment 8

[Hubert B Manilla]

(In reply to Nick Fitzgerald [:fitzgen][:nf] from comment #7)
> I'm not really on top of the new work going on for code coverage. Perhaps
> jlongster is a better point of contact.

Hey nick sorry, mistake! the comment was supposed to be for :ejpbruel

Comment 9

[Eddy Bruel [:ejpbruel]]

(In reply to Hubert B Manilla from comment #6)
> Hey Nick,
> NP. i'm still really keen on digging into this.
> It looks like a couple of things have changed and/or relating to the design
> and stuff.
> Would love to get up to speed.
> 
> Thanks

Hi Hubert. So what we want is to take any traces we receive from the debugger server in the debugger controller, and pass them off to a worker. This worker should then reduce the trace information to something that we can use to highlight executed code in the editor.

A good place to start would probably be DebuggerController.Traces. How familiar are you with that part of the code? If you need more specific help, feel free to let either me or James know in the bug (or ping me o irc in the #devtools channel).

Comment 10

[Hubert B Manilla]

(In reply to Eddy Bruel [:ejpbruel] from comment #9) 
> A good place to start would probably be DebuggerController.Traces. How
> familiar are you with that part of the code? If you need more specific help,
> feel free to let either me or James know in the bug (or ping me o irc in the
> #devtools channel).

Does DebuggerController.Traces still exist in the codebase? I tot it was taking out at some point.
i just double checked now and can't find it.

Comment 11

[Eddy Bruel [:ejpbruel]]

(In reply to Hubert B Manilla from comment #10)
> (In reply to Eddy Bruel [:ejpbruel] from comment #9) 
> > A good place to start would probably be DebuggerController.Traces. How
> > familiar are you with that part of the code? If you need more specific help,
> > feel free to let either me or James know in the bug (or ping me o irc in the
> > #devtools channel).
> 
> Does DebuggerController.Traces still exist in the codebase? I tot it was
> taking out at some point.
> i just double checked now and can't find it.

You are right, it looks like that code has been completely removed. That's a snag :-S

I have to admit that I am not up to date on the current state of the tracer in our codebase. As far as I know, it has not gotten much love lately, so its entirely possible that parts of it have bitrotted and subsequently been removed.

Needinfo'ing James again, since he might know more about the current state of the tracer. If James doesn't know, I'll ask around on irc tomorrow and report back what I find out.

Comment 12

[Eddy Bruel [:ejpbruel]]

(In reply to Eddy Bruel [:ejpbruel] from comment #11)
> (In reply to Hubert B Manilla from comment #10)
> > (In reply to Eddy Bruel [:ejpbruel] from comment #9) 
> > > A good place to start would probably be DebuggerController.Traces. How
> > > familiar are you with that part of the code? If you need more specific help,
> > > feel free to let either me or James know in the bug (or ping me o irc in the
> > > #devtools channel).
> > 
> > Does DebuggerController.Traces still exist in the codebase? I tot it was
> > taking out at some point.
> > i just double checked now and can't find it.
> 
> You are right, it looks like that code has been completely removed. That's a
> snag :-S
> 
> I have to admit that I am not up to date on the current state of the tracer
> in our codebase. As far as I know, it has not gotten much love lately, so
> its entirely possible that parts of it have bitrotted and subsequently been
> removed.
> 
> Needinfo'ing James again, since he might know more about the current state
> of the tracer. If James doesn't know, I'll ask around on irc tomorrow and
> report back what I find out.

As it turns out, we made the decision to completely remove the tracer during the all-hands. Apparently, it had several glaring omissions, which would have required a complete rewrite to fix. We plan to write a new version of the tracer eventually, which will be based on tracelogging work in Spidermonkey, but this is not a priority at the moment.

I did not attend the all-hands, so unfortunately I was aware of all this. With the tracer now gone, I'm not sure what API to use in order to implement code coverage. I suspect the best course of action will be to hold off on this feature until we implement a proper tracer. I'm keeping James ni?'d, just in case I missed something else, and he has a better idea.

The tracer has been removed in: https://bugzil.la/117698.

Comment 13

[Hubert B Manilla]

(In reply to Eddy Bruel [:ejpbruel] from comment #12)
> (In reply to Eddy Bruel [:ejpbruel] from comment #11)
> > (In reply to Hubert B Manilla from comment #10)
> > > (In reply to Eddy Bruel [:ejpbruel] from comment #9) 
> > > > A good place to start would probably be DebuggerController.Traces. How
> > > > familiar are you with that part of the code? If you need more specific help,
> > > > feel free to let either me or James know in the bug (or ping me o irc in the
> > > > #devtools channel).
> > > 
> > > Does DebuggerController.Traces still exist in the codebase? I tot it was
> > > taking out at some point.
> > > i just double checked now and can't find it.
> > 
> > You are right, it looks like that code has been completely removed. That's a
> > snag :-S
> > 
> > I have to admit that I am not up to date on the current state of the tracer
> > in our codebase. As far as I know, it has not gotten much love lately, so
> > its entirely possible that parts of it have bitrotted and subsequently been
> > removed.
> > 
> > Needinfo'ing James again, since he might know more about the current state
> > of the tracer. If James doesn't know, I'll ask around on irc tomorrow and
> > report back what I find out.
> 
> As it turns out, we made the decision to completely remove the tracer during
> the all-hands. Apparently, it had several glaring omissions, which would
> have required a complete rewrite to fix. We plan to write a new version of
> the tracer eventually, which will be based on tracelogging work in
> Spidermonkey, but this is not a priority at the moment.
> 
> I did not attend the all-hands, so unfortunately I was aware of all this.
> With the tracer now gone, I'm not sure what API to use in order to implement
> code coverage. I suspect the best course of action will be to hold off on
> this feature until we implement a proper tracer. I'm keeping James ni?'d,
> just in case I missed something else, and he has a better idea.
> 
> The tracer has been removed in: https://bugzil.la/117698.

Ok Cool. Thanks alot!

Comment 14

[James Long (:jlongster)]

We are getting new code coverage APIs here, fwiw: 1176880

Comment 15

[Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat )]

(close it up, jlong?, I am closing 789985 in deference to this.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.