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.

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

Dat ascii

Would be digging into this.

...if its ok?

(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!

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

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

(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

(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).

(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.

(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.

(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.

(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!

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

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