I admit, I’m pretty blown away by the TraceMonkey announcement. I’m envious. I’m still trying to get my company onto Mozilla Firefox 3 code…
That said, one of the biggest questions with JIT compilation of JavaScript that I’ve had for months is, “How are we going to debug JavaScript now?”.
It probably doesn’t help that Venkman didn’t make it into hg.mozilla.org. I think that was intentional, and I don’t dispute it. Still, with Gijs Kruitbosch on vacation, there’s not a lot of people to maintain Venkman (we’ve been down this road before).
Perhaps the right answer with TraceMonkey is to let Venkman die.
Note that I don’t suggest this lightly. Venkman nearly died once with 1.9, and has been on life support for years anyway. With Mozilla 2 breaking backwards compatibility in interfaces – and Venkman left in the dust, not even having automated tests for it (any tests at all?) – by the time we get around to bringing it up to 1.9.1, we may find it simply cannot work with TraceMonkey.
So I’d like to start a general discussion on what sort of JavaScript debugging tools we can craft for Mozilla 2.0. I really, really do care about this – without a good JS debugger, I may be dead in the water for a lot of what I do. (If I’m forced to use and learn DTrace for debugging JavaScript, I’d really like to apply it to a XUL app that can do the work for me.)
Comments are open. Please serious commentary only, not “I want this feature!”. I’m trying to find (and join, and participate in!) a group of people who can spend the time on researching & implementing a solution.
I would understand if Venkman passed on, but it would leave a seriously gaping hole. If we can convince the new Firebug working group to make different branches (something desperately needed, in my opinion), a robust and modern (and maybe a little more approachable) debugger might come out of it, to the benefit of everyone. Since Firebug 1.0, it has grown too big for itself, and splitting it off into chunks would allow each specialized piece to grow even more into the tools we need, especially if Venkman will no longer exist moving forward.
As I understand it, if a debugger is attached, tracing doesn’t happen.
Currently, when a JS debugger is attached, Tracemonkey is automatically disabled. Maybe that’s not ideal, but it’s not the end of JS debuggers.
And the DTrace probes basically fire at the points where the debugging hooks used by Venkman fire anyways. DTrace is interesting because it lets you trace JavaScript and other things, not because it’s any better than the existing JavaScript debugging*.
*Well, the scripts can do some pretty sweet stuff… but it’s still dealing with the same source data.
I’m by no means expert on this, not even remotely close.
But if Tracing and debugger are mutually exclusive, and tracing is here to stay (which probably is), then maybe its time to rethink how debugger works, or if javascript itself need to be adjusted to allow debugger when needed.
From what I heard, Firebug is not yet up to working well with debugging chrome. And it would be a shame for a component in SeaMonkey to die without us being able to replace it with something that is at least almost at par with it.
DOM inspector has recently moved to its own hg repo, I’m pretty sure we can do the same for venkman easily enough, if Gijs and you are interested in that.
If we can get the bugs worked out of chromebug we should probably let Venkman die.
On another note, there is dtrace for debugging Mozilla applications, and in the summit dtrace meeting we did target probes for lots of the new trace work.
A company I’m consulting for is considering donating some money (not a large amount, but every bit counts…) and if there were a well-organized debugger effort that could be taken seriously, I would certainly suggest putting the money there.
Venkman, Firebug and similar tools are very important to us. JavaScript (and related tools) will be even more important to us in the future, possibly replacing some of our C++ components.
I’m really excited about the direction JavaScript is taking. Hope that isn’t just the Mugshots espresso…
The bug that removed the optional argument to eval already made Venkman quite unusable – I’m running with it backported.
Also, it already is not showing the code for XUL files.
The workarounds used for Firebug don’t let me happy.
With Sandboxes is not easy at all to change the values of the properties of a window and see real changes.
As some people said, disabling tracing when a debugger is attached is a nice solution.
That’s almost the same for C code, for instance, when you can’t optimize that much the code, otherwise debugging would be almost impossible – an “optimized value” on GDB makes me cry.
It’s easier and probably cleaner to disallow optimizations while debugging, than making something with considerable run-time costs to make it possible to debug an optimized code.
Should we inline an function and still maintain an reference to it, for instance?
About Venkman itself for Gecko 1.9.1, I would love to see it working and I would like to help.
Although I have no experience on contributing code to Venkman.
IMO, from the SeaMonkey perspective, Venkman is an important part, so I’m willing to help out. OTOH, making Firebug and Venkman “unite” and being available for the Mozilla _platform_ instead of Firefox alone would be a useful endeavour…