DXR Future Work Plan: Difference between revisions

← Older edit

DXR Future Work Plan (view source)

Revision as of 17:16, 31 August 2012

1,380 bytes added , 31 August 2012

no edit summary

Jonasfj

33

edits

@@ Line 1: / Line 1: @@
+<b>This page is currently fairly outdated</b>, some of these future ideas are certainly still applicable. Whilst many of the issue are no-longer applicable, in the current testing branch. At time of writing I strongly recommend reading "docs/" folder from current testing branch before continuing to read this page.
 ==What is DXR?==
@@ Line 9: / Line 11: @@
 ==DXR Bugs==
-* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=product%3Awebtools+component%3Adxr Existing DXR Bugs]
+The complete list of DXR bugs is available [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=product%3Awebtools+component%3Adxr here (WebTools:DXR )]
-* Add DXR bugzilla component - [https://bugzilla.mozilla.org/show_bug.cgi?id=517550 bug 517550]
 * DXR Tracking bug - [https://bugzilla.mozilla.org/show_bug.cgi?id=489834 bug 489834]
 * Deploy DXR at Mozilla - [https://bugzilla.mozilla.org/show_bug.cgi?id=524725 bug 524725]
@@ Line 19: / Line 20: @@
 The current set of tasks can be summarized into the following high-level categories:
+* Improve the DXR web-app backend
 * Improve the indexing of source code and creation of the database and HTML
 * Improve user access to data stored in the database, making it easier to query, search, etc.
@@ Line 25: / Line 27: @@
 Each of these three have sub-tasks, many of which interrelate.
-===Indexing, HTML Generation, Back-end Work===
+===Web App Back-end Work===
+* Switch python web cgi to use django
+* Audit web app for security
+* Start using caching
+* Investigate switching from SQLite to a db server
+* Investigate adding some basic auditing and user feedback:
+** What are people searching for most often?
+** Allow users to star or otherwise mark things that are wrong in the HTML data
+** Perhaps allow users to leave notes, links, etc. in various parts of the code
-* <strike>Start doing continuous re-indexing of the tree</strike> Basic code in place, need to evolve and deploy
+===Indexing, HTML Generation===
-* <strike>Improve post-processing speed, investigate better parallelism</strike> Completed.
+* Build test harness for indexing/html generation
+* Deal with edge cases for builds failing (e.g., don't delete existing an existing index/html set until it's clear that the new build/index is working, cf. builds failing back-to-back)
+* Figure out best method for doing continuous re-indexing of the tree
+** Answer: Build DXR from tinderbox!
+* Add dead-code info (talk to ehren for details)
+* Improve post-processing speed, investigate better parallelism
+** And memory usage
 * Add proper IDL data to source code such that clicking types, members, etc. shows a popup with links to implementations, callers, etc.
 * Fix C++ snippets in IDL to use cpp position indicators (# line file).  Add any other missing IDL features.
+** Switch from using xpidl to xpidl.py and add __FILE__ and __LINE__ data to IDL C++ snippets
+* Fix use of IPIDL ${...} stuff for .cpp.html generation (e.g., Got invalid token in ? @ 353 token:$: 'TED =====\n${INCLUDES' from http://mxr.mozilla.org/mozilla-central/source/ipc/ipdl/test/cxx/IPDLUnitTests.template.cpp#19 -- ${INCLUDES}
 * Look for speed-ups in how analysis builds are done
-* Switch python web cgi to use django
 * Add links for #include header files
-* Add support for C source
-* Add support for static functions (see nsContentUtils)
 * Add support for JS source.  Consider using jshydra to build static HTML.  See js token info in [http://mxr.mozilla.org/mozilla-central/source/js/src/jsscan.h#60 jsscan.h].
 * Add support for Obj-C/C++ source
-* Show compiler warnings
+* Integrate various callgraphs (ehren's, sixgill): convert to using treehydra, investigate --with-static-checking in mozilla's build sys, include dwitte's callgraph.js and my dxr.js (include "callgraph.js").
-* Integrate callgraph: convert to using treehydra, investigate --with-static-checking in mozilla's build sys, include dwitte's callgraph.js and my dxr.js (include "callgraph.js").
 * Tokenize macros so that embedded macros are clickable (e.g., NS_ProcessNextEvent resolves to NS_ProcessNextEvent_P)
-* Investigate ways to deal with naming collisions.  For example, where types, methods, or macros share the same name, sometimes we pick the wrong one for purposes of linkifying (e.g., NS_ProcessNextEvent).
 * Make IDL pages, and other decl locations do a better job at providing links
-* Audit web app for security
 * Fix srcdir vs. objdir links (e.g., PRInt32)
 * Remove .html from source file names (mod_rewrite?)
@@ Line 50: / Line 64: @@
 * Figure out how to deal with code being ifdef'ed out (e.g., debug vs. non-debug build)
 * Audit dehydra script for improvements
-* Treat functions as well as methods
 * Add a download-db link
 * Link to the hg revision of the indexed db (i.e., a timestamp)
+* Investigate minifying html - http://perfectionkills.com/experimenting-with-html-minifier/
 ===Querying, Search===
-* <strike>Switch to using http get for searches</strike> Completed.
-* <strike>Add derived:classname::method query</strike> Completed.
-* <strike>Searching for filenames should work for fullnames vs. initial portions (e.g., nsGlobal or nsGlobalWindow vs. nsGlobalWindow.cpp)</strike> Completed.
 * Make Users queries differentiate decls/defs
 * Add ability to do Users:nsIFrameFrame::GetDocShell
@@ Line 75: / Line 86: @@
 * Add pagination to search results
 * Limit search nav divs to some lower number (12?) and give a link to see the whole thing.
+* Remove JavaScript munging of search box input, so "Add a keyword for this search" works
 ===Source Code View===
@@ Line 88: / Line 100: @@
 * Standardize on look and feel of source code nav bar for members and popups, etc (gray, icons, font)
 * Tighten-up look of popup box
+* Provide mechanism to go from one type to another, showing intermediary steps (QI, method calls, etc. to get from nsIOne to nsITwo) (cjones wants)
 * Fix pop-up position so it isn't off the screen
 * Fix Users query so it includes uses of the type directly in addition to uses of derived types (e.g., nsIFoo might have direct users if not an idl type)
@@ Line 101: / Line 114: @@
 ** Should we integrate [http://www.oxymoronical.com/blog/2010/01/Throwing-xpcom-docs-out-into-the-wild Mossop's XPCOM docs project]?
 ** Connect with MDC (e.g., for XUL docs)
-** Add gcov data
+** Integrate with bug/patch data in bugzilla
+** Dead code, should-be-static and other analysis data
 * Add Macro decl locations
 * Investigate strategy for increment re-indexing vs. full clobbers
 * Add support for html/xml, perhaps with links to MDC doc pages
 * Multi-platform indexing
-** MSVC++ may be doable with this: [http://msdn.microsoft.com/en-us/library/87x7wc99.aspx]
+** MSVC++ may be doable with this: http://msdn.microsoft.com/en-us/library/87x7wc99.aspx
-* Add gcov support
 * Add build dependency map info - "what do I have to remake if I change something in content/html/document/src?"
 * Add control mechanism for running dxr continuously.  Maybe web based?  Maybe as part of buildbot with waterfall?
+* Patch/Review features: try-server type system that checks the patch for issues, but perhaps dxr should be used to visualize the results.  Show things like, new warnings/issues/deadcode.  Also, given a patch, show everything DXR knows about the patch and code affected by it.
+* derived: search should also provide an interactive inheritance diagram