Poll: What do you need in MXR/DXR?

[Erik Rose]

What features do you most use in MXR and DXR?

Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities.

What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?)

If you're already using DXR as part of your workflow, what could it do to make your work more fun?

Feel free to reply here, or attach a comment to this blog post, which talks about some of the things we've done recently and are considering for the future:

https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/

We'll use your input to build our priorities for Q4, so wish away!

Cheers,
Erik

[Benoit Jacob]

I need:
- DXR permanent code links i.e. code links to a particular hg changeset,
not to "tip", so that I can paste code links on a bug and they stay valid.
Currently I fall back to hg.mozilla.org for that use case.
- Easy access to hg annotate, as in mxr (could be better than mxr even, by
integrating into the existing view instead of being a separate view).

Benoit


2013/10/2 Erik Rose <er...@mozilla.com>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Dave Townsend]

This is looking awesome and I'm going to attempt to switch my mxr quick
searches over to it. A couple of immediate things that you might want to
think about:

Right now I think mxr updates from mozilla-central faster than daily. I've
used that on a number of occasions to figure out what has broken my
build/patch.

One of the neat things with mxr and multiple trees is that when viewing a
file on say mozilla-central I can easily switch to the mozilla-aurora
version to see how it looks there, this is really useful for figuring out
how a bug affects different branchs. Bonus points might include a file diff
between the trees.

[Erik Rose]

> - Easy access to hg annotate, as in mxr (could be better than mxr even, by integrating into the existing view instead of being a separate view).

Assuming I understand you right, we've just added this last week. :-) See the Blame link at http://dxr.mozilla.org/mozilla-central/source/embedding/base/nsIDialogCreator.idl. RIght now, we're just delegating out to hgweb, but inlining is something we could do in the future.

Great stuff! Keep it coming!

[Erik Rose]

> One of the neat things with mxr and multiple trees is that when viewing a file on say mozilla-central I can easily switch to the mozilla-aurora version to see how it looks there, this is really useful for figuring out how a bug affects different branchs. Bonus points might include a file diff between the trees.

Very cool. I actually heard this use case while I was working on the new UI wireframes, and you've solidified it. I've added a note to amplify it at https://wiki.mozilla.org/DXR_UI_Refresh#Other_Considerations_.26_Use_Cases. Thanks! Keep it coming; let me know how trying your searches on DXR goes.

Erik

[Axel Hecht]

Could you add an l10n tree to dxr? I'd love to dogfood before I comment.

Extra cookie if you're getting to gaia-l10n before mxr does,
https://bugzilla.mozilla.org/show_bug.cgi?id=795709 :-)

Axel

[Ehsan Akhgari]

DXR is looking awesome these days!

I find the call graph information to be wrong some of the time, I have
never been able to tell why. See this query for example:
<http://dxr.mozilla.org/mozilla-central/search?q=%2Bcallers%3A%22mozilla%3A%3AAudioNodeStream%3A%3ASetDoubleParameter%28uint32_t%2C+double%29%22>.
Do you have any idea what the source of these problems is, and if yes,
is that on track to get fixed?

Thanks!
Ehsan

On 2013-10-02 3:33 PM, Erik Rose wrote:
> What features do you most use in MXR and DXR?
>
> Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities.
>
> What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?)
>
> If you're already using DXR as part of your workflow, what could it do to make your work more fun?
>
> Feel free to reply here, or attach a comment to this blog post, which talks about some of the things we've done recently and are considering for the future:
>
> https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/
>
> We'll use your input to build our priorities for Q4, so wish away!
>
> Cheers,
> Erik

[Mike Conley]

I love DXR for mozilla-central, and would love it if the UX branch
(https://mxr.mozilla.org/projects-central/source/ux/) was indexed there
as well!

Keep up the great work,

-Mike

[Terrence Cole]

I've been using DXR (at least when it has been working) since 2011. One
thing I'd like to see should be simple to implement: typing a file name
into the search bar should find that file rather than nothing.

[Boris Zbarsky]

On 10/2/13 3:33 PM, Erik Rose wrote:
> What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?)

MXR things I use constantly that don't seem to have obvious dxr
counterparts:

* Search on the "firefox" tree to follow pre-hg blame.

Features that are really handy at times (though the discoverability in
mxr is terrible, so maybe dxr just has the same issue):

* Linking to particular versions.
* Marking particular lines.

Things that drive me nuts about mxr when I've tried to use it:

* When navigating down the directory/file tree, it keeps autofocusing
the search field, which is super-annoying if you're using keyboard-only
navigation (with quickfind and enter) to do the traversal.

-Boris

[Gijs Kruitbosch]

Something that's been bothering me about MXR for many years: When I
search for any file of which there is only one copy, like any of the
interface definition files, or the singleton implementations thereof, it
should just open the file. The extra click on the unique search result
is just wasted time.

~ Gijs

[Justin Wood (Callek)]

Few things for me that I don't see an easy way to do on dxr.m.o right
now at a glance.

Search `file names` I might remember a file is called sut_lib for
example, but unsure extension or where it is, but know I need to edit it!

Search text strings within a specific filename wildcard, e.g. I might
want a search for some method in any idl, but not care about the
underlying implementation in C++

Further insight I can't easily provide unless
http://mxr.mozilla.org/build and http://mxr.mozilla.org/comm-central/ is
replicated at dxr, I can provide insight on what the req's are for both
setups (since build/ is many repos, while comm-central is 2 large repos
and a few small ones)

- For me personally comm-central is less important for my testing since
mozilla-central meets most of the needs in useability.

~Justin Wood (Callek)

[Nicholas Cameron]

Could we run with DEBUG on? We'd index strictly more code (I think) and sometimes I miss debug-only things.

(One day I would love to get Windows-only stuff indexed, but I guess we have to wait for Clang to work on Windows for that).

Nick

[Nick Alexander]

For every use case, there is an equal and contradictory use case: I find
DXR's "jump to the only result" behaviour frustrating. I have separate
mxr and mxrf keywords for searching in files; if mxrf jumped to the
unique result, I would be irritated (because I often just want to see
what the full path to the file is, like `git ls-files | grep`).

Nick

[Dave Townsend]

On Wed, Oct 2, 2013 at 1:52 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> On 10/2/13 3:33 PM, Erik Rose wrote:
>
>> What keeps you off DXR? (What are the MXR things you use constantly? Or
>> the things which are seldom-used but vital?)
>>
>

> Things that drive me nuts about mxr when I've tried to use it:
>
> * When navigating down the directory/file tree, it keeps autofocusing the
> search field, which is super-annoying if you're using keyboard-only
> navigation (with quickfind and enter) to do the traversal.

Absolutely this!

[Bill McCloskey]

I would like better documentation about how to use dxr. I know it's pretty powerful, but it's always just easier for me to use mxr than to figure out the right query. One that would be really useful to me is to find all references to a field of a given class. If dxr's main search page had some examples of how to do searches like this one, that would be great. Someone once showed me a way to get it to pop up a little window with options like "function:" and "type:" (although I seem to have lost that dialog and I can't figure out how to get it back). However, there's no explanation of what these operators do and I can't get them to work. For example, if I search for "function:JS_SetGCZeal" I get no results. Why is that?

-Bill

----- Original Message -----
> From: "Dave Townsend" <dtow...@mozilla.com>
> Cc: dev-pl...@lists.mozilla.org
> Sent: Wednesday, October 2, 2013 2:47:19 PM
> Subject: Re: Poll: What do you need in MXR/DXR?
>
> On Wed, Oct 2, 2013 at 1:52 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>

[Steve Fink]

On Wed 02 Oct 2013 12:33:40 PM PDT, Erik Rose wrote:
> What features do you most use in MXR and DXR?
>
> Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities.
>

> What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?)
>

> If you're already using DXR as part of your workflow, what could it do to make your work more fun?

Overall, I really like dxr. Especially the speed. But the incremental
results, while cool, are done in a way that makes me feel like I'm not
in control. I'm not sure when it's still thinking. It all feels a
little too magic. But anyway, on to some specific items. Just one or
two, ok?:

* The search boxes don't work for setting up keyword searches. Er...
wait, the main box actually just worked for that for the first time! It
used to be missing the tree name, I guess? But it's still problematic
to use any of the advanced search boxes.

* Related bug:
1. Clear out all the advanced search choices
2. Enter "Foo" into the "function-ref" box
3. Right-click on the "function" box, add a keyword search (say it's
'dxr1')
4. Ctrl-L, enter "dxr1 Bar"

Result: function-ref box gets filled with "Foo?substring-search="

Desired result: dxr1 is a valid keyword search for either
"function:Bar" or "function:Bar function-ref:Foo". I don't really care
which.

* Related bug 2:
1. Enter any random search at the main page to get to the results page.
2. Clear out all fields in the advanced search box
3. Add a keyword search for the "function" box

Result: the keyword search remembers the original search, the one that
you manually cleared out.

* I find the Advanced Search box confusing. I'm not sure whether it's
ORing or ANDing my results. (I mean, it's pretty easy to figure out if
you search for known stuff.) At the very least, I would like a stronger
visual indicator of which fields are being used (nonempty). The
auto-updating main search bar definitely helps with this, but it's not
enough for simpletons like me. Having a "Clear All" or "Reset" button
would help too.

* UI jumps around a lot while it's populating the incremental results.
Moves the incremental functionality from "cool" to "annoying".

* The lag in the incremental results view when I switch searches feels
bad. eg I have some set of results open, and I wipe out my search and
replace it with a new one. For some amount of time, I see the old
results, with no progress indicator telling me that they're out of date
and it's refreshing. In general, it needs a better activity indicator,
even when refining existing results.

* Tooltips on the advanced search options! I totally have to guess what
"function" vs "function-ref" means. Is "function" any occurrence, just
declarations, just definitions, or ? "Function *reference*" makes me
think of a C++ &reference, too. I don't know what the "warning" search
does, since its example returns no results. Do the advanced search
criteria icons show up anywhere else in the UI? Right now, they seem
like visual noise, but if they appeared alongside something else
(results?), I might get to like them.

* I don' t see a way to go from the results screen to the source code
browsing, other than clicking on the icon to get back to the "main"
screen and following the link there. Ok, maybe this is only a problem
because I don't see any point in the main screen. It goes away quickly
and it's not obvious how to get back to it, so why does it even exist?

* I don't know what makes the Advanced Search box and Navigation boxes
appear or disappear, nor how to get them back when they're not there.
The thing seems to have a mind of its own -- I just switched back to it
from writing this message, and it somehow had mozilla-central/AUTHORS
selected. Is there some weird onBlur behavior? Eh, maybe I clicked
something without meaning to.

Oh! The advanced search box appears when you press enter. But there's
no visible reason to ever have to press enter, so it's easy to miss.

* The regexp field not only requires the /slanted brackets/, but it
ignores the 1st and last characters no matter what they are. (I entered
"fprintf", and it showed me matches for "print".)

* It's been said, but the source links should have a revision in them
so they're stable. I don't know how to reconcile that with having them
point to dxr, since presumably dxr indexes only one version.

* Does dxr have access to other static information? Eg, can I see a
list of callers/callees of a function?

* The search box icon (a dinosaur in a magnifying glass) makes it look
like you're looking through the wrong end of binoculars -- surely it's
making the dinosaur *smaller*, not bigger, given its size? :-) (Please
ignore this comment.)

[Justin Dolske]

On 10/2/13 1:48 PM, Terrence Cole wrote:
> I've been using DXR (at least when it has been working) since 2011. One
> thing I'd like to see should be simple to implement: typing a file name
> into the search bar should find that file rather than nothing.

I'd like support for file/directory name matching in general. I'm not at
all fond of how MXR implements it UI-wise, but I find myself frequently
doing things like:

* Limiting searches to a particular file type. (eg, "image" in CSS files)

* As a jump point when I know a filename (eg, "nsILogin", click search,
click the particular IDL I wanted).

* Limiting searches to a subtree (in one step), or to a directory
pattern (eg "test").

A basic "file:" keyword hint with simple wildcard globing could do most
of it well enogh, I think... "file:*.css", "file:nsILogin*", "file:/test*"

Justin

[Justin Dolske]

On 10/2/13 12:33 PM, Erik Rose wrote:

> What keeps you off DXR? (What are the MXR things you use constantly?
> Or the things which are seldom-used but vital?)

First -- this work is really awesome. DXR already feels like it's close
to being something I can switch over to. If for no other reason than it
being omgfast!

Support for image browsing would be super helpful for front-end stuff.

Compare

http://dxr.mozilla.org/mozilla-central/source/toolkit/themes/windows/global/icons

with

http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/windows/global/icons/

(Maybe this is just a bug? In general I'd expect all files to show up
when browsing a directory.)

Justin

[Ehsan Akhgari]

On 2013-10-02 4:52 PM, Boris Zbarsky wrote:
> On 10/2/13 3:33 PM, Erik Rose wrote:
>> What keeps you off DXR? (What are the MXR things you use constantly?
>> Or the things which are seldom-used but vital?)
>
> MXR things I use constantly that don't seem to have obvious dxr
> counterparts:
>
> * Search on the "firefox" tree to follow pre-hg blame.

We may be able to use https://github.com/mozilla/mozilla-central for
blames since that repository contains the full history (including pre-hg
times.)

Ehsan

[Ehsan Akhgari]

On 2013-10-02 5:31 PM, Nicholas Cameron wrote:
> Could we run with DEBUG on? We'd index strictly more code (I think) and sometimes I miss debug-only things.
>
> (One day I would love to get Windows-only stuff indexed, but I guess we have to wait for Clang to work on Windows for that).

clang is working on a cl.exe compatible driver. Once that is closer, it
should be relatively easy to support clang-cl.exe on Windows.

Cheers,
Ehsan

> Nick
>
> On Thursday, October 3, 2013 8:33:40 AM UTC+13, Erik Rose wrote:
>> What features do you most use in MXR and DXR?
>>
>>
>>
>> Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities.
>>
>>
>>
>> What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?)
>>
>>
>>
>> If you're already using DXR as part of your workflow, what could it do to make your work more fun?
>>
>>
>>
>> Feel free to reply here, or attach a comment to this blog post, which talks about some of the things we've done recently and are considering for the future:
>>
>>
>>
>> https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/
>>
>>
>>
>> We'll use your input to build our priorities for Q4, so wish away!
>>
>>
>>
>> Cheers,
>>
>> Erik

[Ehsan Akhgari]

On 2013-10-03 2:31 AM, Justin Dolske wrote:
> On 10/2/13 1:48 PM, Terrence Cole wrote:
>> I've been using DXR (at least when it has been working) since 2011. One
>> thing I'd like to see should be simple to implement: typing a file name
>> into the search bar should find that file rather than nothing.
>
> I'd like support for file/directory name matching in general. I'm not at
> all fond of how MXR implements it UI-wise, but I find myself frequently
> doing things like:
>
> * Limiting searches to a particular file type. (eg, "image" in CSS files)

<http://dxr.mozilla.org/mozilla-central/search?q=image%20path%3A*.css>

> * As a jump point when I know a filename (eg, "nsILogin", click search,
> click the particular IDL I wanted).
>
> * Limiting searches to a subtree (in one step), or to a directory
> pattern (eg "test").

<http://dxr.mozilla.org/mozilla-central/search?q=node%20path%3Awebaudio%2F>

> A basic "file:" keyword hint with simple wildcard globing could do most
> of it well enogh, I think... "file:*.css", "file:nsILogin*", "file:/test*"

s/file/path/

:-)

Ehsan

[Nicolas B. Pierron]

Hi,

On 10/02/2013 12:33 PM, Erik Rose wrote:
> What features do you most use in MXR and DXR?

First of all I am using DXR since a while and I love it interface which give
a contextual navigation as opposed to MXR.

One of the feature I miss in DXR as opposed to MXR is that double-quotes are
interpreted as part of the search and not only the content of the search.

> If you're already using DXR as part of your workflow, what could it do to make your work more fun?

The code base is compiled for multiple platforms. Currently I cannot find
the functions which are defined on ARM unless we use a search as we used to
do on MXR.

DXR gives a nice contextual navigation, but the size of the code base is
overwhelming to have a clear understanding of what is going on. One of the
thing that I am looking at in general is to understand the conditionals
which are giving a particular result, or the consequences of a statement.
Such overview is hard to get when you have ~30 DXR tabs opened. I would
love to have a graph overview of these relations, as well as seeing the
conditionals/guards as part of the graph.

Great Work :)

--
Nicolas B. Pierron

[Ehsan Akhgari]

On 2013-10-03 3:24 PM, Nicolas B. Pierron wrote:
> The code base is compiled for multiple platforms. Currently I cannot
> find the functions which are defined on ARM unless we use a search as we
> used to do on MXR.

This is a fundamental problem with DXR and will be difficult to fix,
because the DXR compiler will only see one configuration of the build,
and even if we compiled the code with multiple configurations, it would
be difficult to merge the results into a meaningful unified database.

The other option, providing one DXR instance per configuration, may help
but then you need to pick which DXR you want to search in, which is not
ideal.

That being said, the DXR plaintext search should cover the ARM cases in
the JIT code, right?

> DXR gives a nice contextual navigation, but the size of the code base is
> overwhelming to have a clear understanding of what is going on. One of
> the thing that I am looking at in general is to understand the
> conditionals which are giving a particular result, or the consequences
> of a statement. Such overview is hard to get when you have ~30 DXR tabs
> opened. I would love to have a graph overview of these relations, as
> well as seeing the conditionals/guards as part of the graph.

Can you please clarify what you mean here?

Ehsan

[Steve Fink]

* It doesn't know that #include "mozilla/*" can be found in mfbt/*, so
those headers aren't linkified.

[Steve Fink]

On Thu 03 Oct 2013 03:36:08 PM PDT, Steve Fink wrote:
> * It doesn't know that #include "mozilla/*" can be found in mfbt/*, so
> those headers aren't linkified.

Whoops, wrong. I was looking at an autogenerated header.

I do notice that when viewing jsapi.h, it can find all of headers in
js/public except for Utility.h and Vector.h. Odd.

[Joshua Cranmer 🐧]

On 10/2/2013 2:33 PM, Erik Rose wrote:
> What features do you most use in MXR and DXR?
>

> Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities.
>
> What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?)
>

> If you're already using DXR as part of your workflow, what could it do to make your work more fun?

Things I would like if I didn't have to implement them:
1. Merge multiple build configuration databases somehow.
2. Include Doxygen/Javadocs-like documentation. For C, C++, IDL, Java,
JS, etc.
3. Support for generated files in indexing
4. Better support for JS, Python, etc.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

[Brian Smith]

On Wed, Oct 2, 2013 at 12:33 PM, Erik Rose <er...@mozilla.com> wrote:
> What features do you most use in MXR and DXR?

Blame. I wish blame mode was the default (only?) view.

> What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?)

* Linking to a specific line of a specific revision.
* NSPR and NSS repos
* pre-Mercirual CVS history.

> If you're already using DXR as part of your workflow, what could it do to make your work more fun?

* When in blame mode, the revision number of the most change to the
line is shown. I would like a link next to every line's revision
number that links to the *previous* revision where the line changed.
That way, I can navigate the change history much easier.

* When I click on the revision number next to a line in blame, I would
like that to navigate me to that line in the side-by-side diff view.
And, I want the side-by-side diff view to ALSO have blame revision
numbers, that allow me to navigate the side-by-side diffs' revision
history in a manner similar to previous point.

* I would like all of these things to be integrated into the editor of
Visual Studio 2012. (Perhaps this is out of scope of your group.)

Cheers,
Brian

[Erik Rose]

Added with gusto. This actually drives me crazy, too. :-)

On Oct 2, 2013, at 14:47 , Dave Townsend <dtow...@mozilla.com> wrote:

>> Things that drive me nuts about mxr when I've tried to use it:
>>
>> * When navigating down the directory/file tree, it keeps autofocusing the
>> search field, which is super-annoying if you're using keyboard-only
>> navigation (with quickfind and enter) to do the traversal.
>
>

> Absolutely this!

[Benjamin Peterson]

Erik Rose <erik@...> writes:

>
> What features do you most use in MXR and DXR?

This is probably rather low priority, but MXR can be loaded over https, and
DXR can not currently.

[Nicolas B. Pierron]

On 10/03/2013 02:38 PM, Ehsan Akhgari wrote:
> On 2013-10-03 3:24 PM, Nicolas B. Pierron wrote:
>> The code base is compiled for multiple platforms. Currently I cannot
>> find the functions which are defined on ARM unless we use a search as we
>> used to do on MXR.
>
> This is a fundamental problem with DXR and will be difficult to fix, because
> the DXR compiler will only see one configuration of the build, and even if
> we compiled the code with multiple configurations, it would be difficult to
> merge the results into a meaningful unified database.
>
> The other option, providing one DXR instance per configuration, may help but
> then you need to pick which DXR you want to search in, which is not ideal.
>
> That being said, the DXR plaintext search should cover the ARM cases in the
> JIT code, right?

Right, but you need to spawn a search in such cases.

>> DXR gives a nice contextual navigation, but the size of the code base is
>> overwhelming to have a clear understanding of what is going on. One of
>> the thing that I am looking at in general is to understand the
>> conditionals which are giving a particular result, or the consequences
>> of a statement. Such overview is hard to get when you have ~30 DXR tabs
>> opened. I would love to have a graph overview of these relations, as
>> well as seeing the conditionals/guards as part of the graph.
>
> Can you please clarify what you mean here?

I mean that if we could keep track of the relation followed while browsing
the code such as caller / callee / references, this could help build a nice
graph overview of how the code is shaped, and help the navigation and
understanding of the code.

--
Nicolas B. Pierron

[Erik Rose]

That should be easy enough; I expect it doesn't have any dependencies the mainline moz-central has. I'll add it to the list to try for in Q4!

[Cameron McCormack]

Brian Smith wrote:
> * When in blame mode, the revision number of the most change to the
> line is shown. I would like a link next to every line's revision
> number that links to the *previous* revision where the line changed.
> That way, I can navigate the change history much easier.

Yes, I think being able to navigate the revision history like this is
key to making minor edits like white space only changes etc. less
disruptive.

[smaug]

- Clicking on macros seem to lead to some results, but definitely not the one I'd expect -
the definition of the macro.

- Trying to find files is hard. (Still haven't figured out how to get easily from the main page to Navigator.cpp on dom/base)

- "cycleCollection" on the right side may or may not do something useful.
In most cases it just ignores all the stuff, so it might be better to not have it at all.

- How to mark certain range of code on particular revision?

On 10/02/2013 09:33 PM, Erik Rose wrote:
> What features do you most use in MXR and DXR?
>

> Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities.
>

> What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?)
>

> If you're already using DXR as part of your workflow, what could it do to make your work more fun?
>

[Erik Rose]

What a lot of great input! Thank you! I'll reply individually to those I've missed in the days after the Summit.

In case you happen to be at the Mozilla Summit in Santa Clara, we're holding a DXR design session to mash all that juicy input together and make sure we have a UI/UX sketch that enables it.

Meet us at 14:30 in the Lounge by the whiteboard. I'm working right now on collecting and summarizing all the suggestions from this thread so we can shuffle them around more easily; expect a lot of additions to https://wiki.mozilla.org/DXR_UI_Refresh#Basic_Searchuse case in the next few hours.

Cheers,
Erik

[Nicolas B. Pierron]

After discussing with Eshan, it seems like being able to add/remove lines of
context to any search would be good step forward.

--
Nicolas B. Pierron

[Jesse Ruderman]

Features I'd like:

* Show declarations and definitions (including webidl!) above refs
* context:3
* context:statement
* Search only within string literals / "search by color"
* A way to load ALL results (other than holding Cmd+Down)
* Offer `hg grep --all --follow word file` when I click a word

URL tweaks I'd like:

* Remove &redirect=true
* Fix redundant "mozilla-central/search?tree=mozilla-central"
* Fix confusing #l5 (line 5 or line 15?)

[Jens Müller]

Am 02.10.2013 21:33, schrieb Erik Rose:
> What features do you most use in MXR and DXR?

I'd like to have the index generated by MXR/DXR integrated into an IDE
(e.g., Eclipse, although I am currently not all satisfied with the
handling of mixed C++/JS projects in Eclipse ...).

[Neil]

Erik Rose wrote:

>What are the MXR things you use constantly?
>
>

I can't seem to get the advanced search form to work at all. (It does at
least tell me the prefixes that I can use in the simple search form, but
it's not 100% clear what they mean.) When it does work I would like a
direct link to it and I would like the advanced search fields to retain
their values between searches.

Nor can I seem to get regexp search to work; I never get any results.

For comparison I had recently performed the following MXR query:
http://mxr.mozilla.org/mozilla-central/search?string=iterator&find=%5C.js&filter=%5Cb_%2Aiterator_%2A%5Cb

I started by searching DXR for iterator but it thought I wanted
http://dxr.mozilla.org/mozilla-central/source/build/stlport/stlport/iterator?from=iterator#l1
rather than a text search. However
http://dxr.mozilla.org/mozilla-central/search?tree=mozilla-central&q=iterator+ext%3Ajs*&redirect=true
came close.

(The purpose of my query was to find cases like
http://dxr.mozilla.org/mozilla-central/source/toolkit/components/osfile/modules/osfile_async_front.jsm#l840
which may need to be cleaned up after bug 907077.)

--
Warning: May contain traces of nuts.

[Gijs Kruitbosch]

http://dxr.mozilla.org/mozilla-central shouldn't 404, but do something
useful (probably redirect to either root or %source/)

~ Gijs

[Erik Rose]

> - Clicking on macros seem to lead to some results, but definitely not the one I'd expect -
> the definition of the macro.

For example, if you click ROLE at http://dxr.mozilla.org/mozilla-central/source/accessible/src/base/RoleMap.h#l34, does the "Jump to definition" item from the context menu not work for you?

> - "cycleCollection" on the right side may or may not do something useful.
> In most cases it just ignores all the stuff, so it might be better to not have it at all.

Sorry, can you elaborate on that? I'm not sure what you mean.

Thanks for the feedback!
Erik

[Mook]

On 10/02/2013 12:33 PM, Erik Rose wrote:
> What features do you most use in MXR and DXR?

(Apologies for the late reply; didn't really check newsgroups during the
summit - bad wifi and having too much to do. Didn't about the design
session in SC for the same reason.)

I look up XPCOM interfaces a lot; as an example,
http://dxr.mozilla.org/mozilla-central/search?q=nsIObserverService
doesn't seem very useful - the actual interface definition is near the
bottom. The various type/function/whatever forms in the advanced search
just returns nothing. (Other than the path search, of course, but not
all interfaces are files named after them.) The equivalent webidl
search would be something like
http://dxr.mozilla.org/mozilla-central/search?q=HTMLBaseElement
(type:HTMLBaseElement finds no results).

++ on unifying identifier search (across types of identifiers), tree
switching, blame integration, rev pinning, etc - things already covered
by the wiki. (In roughly that order.)

HTH,

--
Mook
(now with a face XD )

[Nicholas Nethercote]

On Wed, Oct 9, 2013 at 1:49 AM, Neil <ne...@parkwaycc.co.uk> wrote:
>
> Nor can I seem to get regexp search to work; I never get any results.

If you're using the regexp field in the advanced search, you're
probably failing to put '/' (or some other delimiter) at the start and
end. I too was having trouble with this until very recently.

Nick

[Neil]

Thanks, that made regexp: search work for me.

[Georg Fritzsche]

I'd like to see:
- carrying over the line numbers from the URL to the blame link

On Oct 2, 2013, at 9:43 PM, Benoit Jacob <jacob.b...@gmail.com> wrote:
> - DXR permanent code links i.e. code links to a particular hg changeset,
> not to "tip", so that I can paste code links on a bug and they stay valid.
> Currently I fall back to hg.mozilla.org for that use case.

Yes please. Could we default the line links left-hand in source views to something revision specific?

Georg

[Andrew Halberstadt]

Better python support. For example, the function name parameter doesn't
work with ext: .py

http://dxr.mozilla.org/mozilla-central/search?q=function%3Astart%20ext%3A.py
<-- no results
http://dxr.mozilla.org/mozilla-central/search?q=%22def%20start%22%20ext%3A.py
<-- results

On 10/02/2013 03:33 PM, Erik Rose wrote:
> What features do you most use in MXR and DXR?
>

[Erik Rose]

Thanks, everyone, for your thoughtful and voluminous input! I bequeath you the following behind-the-scenes links so you can see the effect your feedback is having on DXR's future.

We've collected, de-duped, and categorized your feedback at https://wiki.mozilla.org/DXR_UI_Refresh#Feedback. If you see your request grossly mischaracterized or omitted, feel free to edit. I'm watching the page.

I've done a first cut at immediate goals just above that, at https://wiki.mozilla.org/DXR_UI_Refresh#Plans_And_Priorities.

Finally, there's a rough draft at a revised (and more sensical) query syntax up at https://github.com/erikrose/dxr/blob/query-parser/docs/queries.rst.

This is just the beginning. I'll be posting updates at https://blog.mozilla.org/webdev/tag/dxr/ whenever there's something useful to say, and you can watch the DXR_UI_Refresh wiki page if you want more frequent updates.

Cheers,
Erik

[Erik Rose]

> Better python support. For example, the function name parameter doesn't work with ext: .py
>
> http://dxr.mozilla.org/mozilla-central/search?q=function%3Astart%20ext%3A.py <-- no results
> http://dxr.mozilla.org/mozilla-central/search?q=%22def%20start%22%20ext%3A.py <-- results

To clarify, it's not the ext:.py that throws it off; it's just that DXR's indexer doesn't understand Python code at all right now. Picking functions, vars, etc. out of JS and Python are things I'd like to work on in the future. I was surprised to see how little they came up in this thread, but I suppose trees and UI niggles are more bothersome right now. After all, if the code you want to search isn't there, you don't have much recourse. :-) Until then, searching for "def foo" is a pretty decent workaround. In fact, any static analysis of Python, no matter how fancy, will have trouble going much beyond that given the dynamicity of the language. However, I have high hopes for making probabilistic call graphs accurate enough to be useful.

Erik

[Henri Sivonen]

On Wed, Oct 2, 2013 at 10:33 PM, Erik Rose <er...@mozilla.com> wrote:
> What features do you most use in MXR and DXR?

String search. Then identifier search. In this order, because I don't
trust the latter to recognize all identifiers. It would help to be
able to trust.

> What keeps you off DXR?

Main reason I've stayed away from DXR is that DXR made scrolling
weird. It seems now better than I recalled, but after landing on a
page, it still seems to require a click before the page down key
works, which is bad.

> If you're already using DXR as part of your workflow, what could it do to make your work more fun?

I could really use links to CVS blame. mxr-test used to have these.
Possibly, having a DXR that browses a git repository that contains the
CVS history from before hg rev 0 in addition to the hg history could
be even better than having links to CVS blame. Dunno. Surprisingly
often, I need to figure out why some code was introduced in 1998-2001.

--
Henri Sivonen
hsiv...@hsivonen.fi
http://hsivonen.iki.fi/

[Dave Hylands]

Hi Erik,

----- Original Message -----
> From: "Erik Rose" <er...@mozilla.com>
> To: dev-pl...@lists.mozilla.org
> Sent: Wednesday, October 2, 2013 12:33:40 PM
> Subject: Poll: What do you need in MXR/DXR?
>
> What features do you most use in MXR and DXR?

One feature I'd like to see in DXR is the ability to click on a header file shown in a #include and have it be opened.

For example, if I search for ErrorResult, I see

#include "mozilla/ErrorResult.h"

I'd like to be able to click on the #include and have it be opened.

It would also be really nice to have the source and header files which are generated from .idl and .ipdl files be included in the index.

Dave Hylands

[Erik Rose]

>> What features do you most use in MXR and DXR?
>
> One feature I'd like to see in DXR is the ability to click on a header file shown in a #include and have it be opened.
>
> For example, if I search for ErrorResult, I see
>
> #include "mozilla/ErrorResult.h"
>
> I'd like to be able to click on the #include and have it be opened.

You, my friend, are in luck. It so happens that I reimplemented that feature last week. It used to be based on some post-build heuristics and only worked some of the time. Now it sits in the clang compiler plugin and knows exactly what clang knows, so it works all the time. In fact, the only thing keeping it from looking like it works is that we stink at building markup (unbalanced tags! ick!) due to a error-prone and labyrinthian interval-overlap-resolution algorithm, which I'm rewriting as we speak. If all goes well, you should see the results in tomorrow's build, and you shouldn't have any more trouble with includes.

> It would also be really nice to have the source and header files which are generated from .idl and .ipdl files be included in the index.

What I'm rewriting is part of the build process, and that's the process I'd have to refactor to make your request a reality. A question for you: would it be better, from your point of view, to index the generated files or to magically turn up the IDL line "attribute short foo" when you search for "function:GetFoo" or "function:SetFoo"? (I'm not sure both are feasible; I just want to get an early read.)

Thanks!
Erik

[Ehsan Akhgari]

The latter is better in my opinion!

Cheers,
Ehsan

[Dave Hylands]

Going back to the idl is probably the best.

It isn't just attributes, though, its also structure definitions as well, like:
http://dxr.mozilla.org/mozilla-central/source/dom/ipc/PContent.ipdl#l73

So if I'm on this line:
http://dxr.mozilla.org/mozilla-central/source/dom/devicestorage/DeviceStorageRequestParent.cpp#l196
DeviceStorageFreeSpaceParams doesn't show as a known structure (i.e. no Jump to definition)

Dave Hylands

[Erik Rose]

> Going back to the idl is probably the best.
>
> It isn't just attributes, though, its also structure definitions as well, like:
> http://dxr.mozilla.org/mozilla-central/source/dom/ipc/PContent.ipdl#l73
>
> So if I'm on this line:
> http://dxr.mozilla.org/mozilla-central/source/dom/devicestorage/DeviceStorageRequestParent.cpp#l196
> DeviceStorageFreeSpaceParams doesn't show as a known structure (i.e. no Jump to definition)

Yep. I was just using the attr as an example. Once we get through the current priorities, I'll take a look at the IDL language and see how huge it is, how strongly we can reason about which symbols point to what, and so on. That'll inform whether we put together an IDL plugin for DXR or just index [some] generated files. I'm sure I'll have more questions in the course of that. Thanks for the feedback!

Erik

[Dave Hylands]

----- Original Message -----
> From: "Erik Rose" <er...@mozilla.com>
> To: "Dave Hylands" <dhyl...@mozilla.com>
> Cc: "Ehsan Akhgari" <ehsan....@gmail.com>, dev-pl...@lists.mozilla.org
> Sent: Friday, October 25, 2013 10:58:02 AM
> Subject: Re: Poll: What do you need in MXR/DXR?
>

Thanks for a great tool :)

Dave Hylands

[Zack Weinberg]

On 2013-10-25 11:10 AM, Ehsan Akhgari wrote:
> On 2013-10-25 10:45 AM, Erik Rose wrote:

>> ... would it be better, from your point of view, to

>> index the generated files or to magically turn up the IDL line
>> "attribute short foo" when you search for "function:GetFoo" or
>> "function:SetFoo"? (I'm not sure both are feasible; I just want to get
>> an early read.)
>
> The latter is better in my opinion!

If I can have only one, I agree the latter is better -- but I want to
mention that sometimes I've needed to see what the I(P)DL compiler has
produced from a particular definition file in order to fix a bug. For
instance, a few years ago -- this may have been fixed since -- there
were many gaps in the documentation of what C++ types corresponded to
IDL types and vice versa, so one had to look at all three of the IDL,
the generated .h, and the hand-written .cpp that expected to implement
an interface to understand what was *really* going on.

So, if you can make DXR do both, that would be better. (With a clear
indication that certain files are generated, and where the real source
is, if at all possible.)

zw

[Shih-Chiang Chien]

First of all, thanks you guys who working of DXR. It is my major tool for studying the Gecko code base and it helps a lot.
I would like to have DXR lists all the implementation of a virtual function. This is quite handy when you are studying an interface which has more than one level of inheritance hierarchy.

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform