MXR your Dehydra
MXR is cool. I use it all the time. But those of us that have been using or creating Dehydra know that Dehydra could be used to make MXR a lot cooler. I don’t seem to have time to work on it, though, so I thought I’d throw some ideas out here, to see if someone thinks it sounds fun and wants to run with it, or (cue ominous chords) if popular demand requires me to do it.
As an example of why Dehydra is needed, look at some random line of source code, like nsHTMLImageAccessible.cpp:238. To know what this does, I want to navigate to the code for SetParent. I can click on it, but then I get a page with links to a dozen or so different SetParent functions, and I don’t know which ones can actually be called on line 238.
To get the right answer, first I have to look up the type variable, privatePrevAccessible, which turns out to be nsPIAccessible. I used MXR to do that, but I had to scan the page for my file name and then pick one of two possible variable definitions (one of which was actually not a definition). So then I can use MXR on SetParent again and search for nsPIAccessible, but I don’t find anything. I try nsPIAccessible in MXR, but I get nothing for that. It would be way too boring to read everything I did after that, but another 10-15 minutes of find, grep, and MXR to find and verify (tracing the ancestry of nsListBulletAccessible was especially tedious) that the SetParent methods that can get called are at
accessible/src/base/nsAccessible.cpp:457
accessible/src/html/nsHTMLTextAccessible.cpp:338
(I know you wouldn’t have been able to sleep tonight until you got the answer.)
Dehydra can do all this automatically. Dehydra knows the type of every variable. Dehydra knows the class hiearchy, so it can find all the concrete classes that that variable can be, and all the SetParent methods those classes have. Dehydra can also look up local variables, parameters, and fields.
So what would I like to see? How about, in MXR, when you click on a reference to a variable or class member, you navigate to the definition(s). And when you click the name in the definition, you get a page listing all the uses. As a starting point, if MXR integration is hard, it would be fine to give, say an MXR URL (which has file name and line number) to some web page, which would then give links for the names on that line of code. One copy/paste is a lot better than 15 minutes of grep. Some AJAX goodness could make the UI easier, too, I imagine. And the identifier search could get an option for whether the input is a function, local variable, etc. (A crazier idea is to get the information in a form Emacs understands to make a smarter tags function.)
(Or does something like this already exist? A quick Google found a program for C, with no plans to produce a C++ version. Has anyone run CScope on Firefox?)
A nice bonus is that because Dehydra is a gcc plugin, the cross-reference builder can run whenever you recompile, so you potentially have your own code immediately added to a local cross-reference database.
Posted: March 3rd, 2008 under Uncategorized.
Comments: 9
Comments
Comment from fredrik (nossralf)
Time: March 4, 2008, 12:21 am
Ever since Taras started working on the Elsa stuff, this has been a vision of mine. Though I have to admit, I was thinking more along the lines of a WSGI-based setup (Python, probably Pylons). I’ve plowed through both LXR/MXR and Bonsai and feel suitably impressed by the people who maintain those snake-pits (vipers, no cuddly boas there). I also have some worry for their mental health.
OpenGrok uses ctags, which is pretty much as “bad” as MXR, and its interface is a bit different as well. Though I expect it’s (much) easier to extend than MXR. But then one would have to code Java…
make -f client.mk gen-xref would be neat. Or gen-doc (I have an IDL parser that spits out DevMo wiki markup.) Heh. It would be cool to have the build system generate an MSDN-type documentation package automagically.
Comment from Zbyněk Winkler
Time: March 4, 2008, 3:24 am
There is this OpenGrok http://opensolaris.org/os/project/opengrok/ – I always wanted to test but all the Java requirements kind of scared me away.
Comment from tmielczarek
Time: March 4, 2008, 4:19 am
I also thought about this recently, and I stuck it on the potential projects list for Seneca student projects:
http://zenit.senecac.on.ca/wiki/index.php/Potential_Projects#gcc_plugin_for_better_mxr_code_parsing
I’m not sure if it’s really a feasible student project or not, but Seneca students have impressed me enough in the past that I believe anything is possible. 
Pingback from BSBlog » Blog Archive » Statically Checking the Mozilla Codebase
Time: March 5, 2008, 8:19 am
[...] Implement a webtool that allows users to browse code exactly [...]
Pingback from Statically Checking the Mozilla Codebase · Get Latest Mozilla Firefox Browsers
Time: March 5, 2008, 10:47 am
[...] Implement a webtool that allows users to browse code exactly [...]
Comment from Josh Matthews
Time: March 5, 2008, 12:29 pm
Summer of Code project, anybody? It actually sounds quite similar to what I’ve been playing with at work. I had to learn the Jam build language, and get up to speed with about 100k of build infrastructure code alone, and the source browser (based on LXR) is not set up to deal with Jam code very well. I’ve been writing a tool in Python that annotates where rules (and variables) and their corresponding actions are defined or invoked, and I plan to put it into a nice Jam browser that can easily punt you around the gigantic build infrastructure, while still remembering where you previously were.
Comment from Sylvain
Time: March 5, 2008, 3:53 pm
@Zbyněk: OpenGrok is very easy to setup: You just need a JVM, ctags package and a Tomcat instance (or other servlet containers). On Linux, I had to raise the max open files limit in /etc/security/limits.conf. That’s much faster than MXR when run locally.
Pingback from Bread and Circuits » Toward a Dehydra-MXR love child
Time: May 16, 2008, 3:53 pm
[...] been following my progress, you’ll know that I’ve been trying to solve Dave’s mxr-dehydra challenge, looking for all possible methods that SetParent could be in [...]
Pingback from Bread and Circuits » DXR pre-alpha: Source Code Lexicography
Time: May 15, 2009, 11:51 am
[...] morning I was able to solve the “Dave Mandelin MXR Problem,” and I’m so happy I had to pause to blog about it. The “Dave Mandelin [...]
Write a comment