Just as a matter of cleaning things up (one less thing to support), I'd
like to disable/redirect lxr.mozilla.org in favor of MXR. Since the
URL structure is the same, I would just make a blanket redirect from
the lxr.mozilla.org domain to mxr.mozilla.org.
We're aiming for Thursday night this week unless I get lots of
complaints.
--
Dave Miller http://www.justdave.net/
System Administrator, Mozilla Corporation http://www.mozilla.com/
I'll complain if the original LXR becomes unavailable. I've already
posted at m.d.a.webtools that I find MXR to be slow -- still, even if
it's in a "production capacity", maybe this is the server or maybe it's
the program, I don't know -- the output is much larger, maybe 40%, but
the time taken to load seems closer to double, if not more. It's become
much less usable for me than LXR, just because it takes too long to get
longer files loaded into the browser (I'm on 1.5Mbps DSL, fwiw).
Timeless saw my post and responded; he agreed with a couple of my
suggestions for reducing the bulk of the data. I'm still not thrilled
with the every-nonkeyword-is-a-link philosophy, but that's not the main
problem.
When I use it to search for a symbol, and then select a line in its
list of results and click on it, very frequently it takes me to a
line of code that does NOT contain the symbol. That's useless.
I always go straight to lxr when that happens, because lxr will not
take me to a wrong line.
For example, visit
http://mxr.mozilla.org/security/search?string=Get.*Cipher.*Info®exp=on&case=on&find=&findi=&filter=&tree=security
and then click on the first match in ssl.h. As I write this, it takes me
to line 476, but the sought symbol does not exist on line 476.
Line 476 is a blank line. The nearest match is lie 468.
This file hasn't changed in 6 months, so it can't be that the DB update
is just a few hours late.
Nice bug. however the bug is present in lxr.mozilla.org too (it's just
moderately painful to prove).
http://lxr.mozilla.org/security/search?string=GetCipherSuiteInfo
GetCipherSuiteInfo
/security/nss/lib/ssl/ssl.h, line 468 -- SSL_IMPORT SECStatus
SSL_GetCipherSuiteInfo(PRUint16 cipherSuite,
/security/nss/lib/ssl/ssl.def, line 116 -- SSL_GetCipherSuiteInfo;
http://lxr.mozilla.org/security/search?string=Get.*Cipher.*Info®exp=yes
Get.*Cipher.*Info
/security/nss/lib/ssl/ssl.h, line 476 -- SSL_IMPORT SECStatus
SSL_GetCipherSuiteInfo(PRUint16 cipherSuite,
/security/nss/lib/ssl/ssl.def, line 124 -- SSL_GetCipherSuiteInfo;
...
So far the lines seem to be consistently off by 8. If we can verify
that, I can easily change MXR to work around this bug in glimpse.
> MXR has been live in a production capacity for the last week or so at
> http://mxr.mozilla.org/
>
> Just as a matter of cleaning things up (one less thing to support), I'd
> like to disable/redirect lxr.mozilla.org in favor of MXR. Since the
> URL structure is the same, I would just make a blanket redirect from
> the lxr.mozilla.org domain to mxr.mozilla.org.
>
> We're aiming for Thursday night this week unless I get lots of
> complaints.
Just so y'all know (it's probably obvious that it hasn't gone away yet)
I heard enough complaints to let them continue side by side for a while
yet. We'll see if MXR improves any as it gets hacked on more.