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…
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.
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.
10 thoughts on “Gecko 1.9.1, TraceMonkey and Venkman?”
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.
*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.
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.
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…
Comments are closed.