On 08/02/2012 03:22 PM, Jim Blandy wrote:
For a long time, these have lived at:
http://hg.mozilla.org/users/jblandy_mozilla.com/archer-mozilla/ However,
I've started putting together a patch to integrate them into the Mozilla
tree, so that anyone who uses a Python-capable GDB will get them
automatically.
Does this sound like a good idea?
I don't know how people survive without these. I use them and love 'em.
I understand the reluctance to add even more flakiness to gdb. But in
practice, I find that when a pretty-printer barfs on something, it's
fairly clear what's going on (it'll insert an error message into the
pretty-printed value's display, which doesn't prevent you from seeing
the rest of the data.) The biggest problem I've had is that something
can go wrong and I'll only get the hex address of certain types, without
the type name. But as long as you notice that things are going off the
rails, you just do a p/r.
* Who can I bug when there's a problem? I volunteer to be on call for
any GDB-Python related issues; there are some other folks on the
team who've hacked on this as well, and I hope they'll volunteer too.
I volunteer to help.
* How are we going to keep the pretty-printers up to date with the
current SpiderMonkey code? SpiderMonkey has changed quickly over the
last couple of years, and the printers have been prone to bit-rot.
Here, I'm asking to impose on the rest of you: I suspect that having
these printers in-tree will make problems show up more quickly, so
we can stay on top of things.
We can do the same thing as we're doing the warnings-and-errors and
rooting analysis builds -- create a single-platform job type on
mozilla-inbound (at least) that only fires off when something is changed
under js/src, and hide it by default. The hiding by default is
unfortunate, but it's currently the recognized way to label something as
"you don't have to backout if this fails. Yet."
Note that in practice, those hidden spidermonkey jobs are only
moderately effective. We do seem to fix them when they break, but
frequently there's a 1-2 week lag in doing so. And the gdb/python stuff
could be a bit worse, since the pool of people familiar enough to fix
them is smaller.
Come to think of it, we should teach tbpl to display a different type of
build: visible by default but informational only. And create a
persistent preference to display spidermonkey builds in that state. I
could do the implementation part of that; not sure about the UI/design part.
My current work in progress is at
https://github.com/jimblandy/mozilla-central. In particular, take a look
at the integrate-archer
<https://github.com/jimblandy/mozilla-central/tree/integrate-archer> branch.
Oh, cool. I have a couple of things piled on top of your original
archer-mozilla repo (eg stack frames and some stuff for moving GCthing
pointers), currently in a half-broken state. I should switch over.
But... why is "archer" still in the name?
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
