It might be sufficient to have a link within the popup "open this in new
window".
The other problem I see with the popup is that it often obscures the very
code I'm trying to read, hence my suggestion about permanent
sidebars/footers/whatever. Have we got a UI designer we can tap to help sort
through this?
I've requested some advice from beltzner, madhava, and faarborg.
Hopefully they will have some good ideas, and I'll raise your concerns
with them. My fear with a side bar is getting the data to fit without
it overtaking the space.
1) Source code
2) Type, statement, inheritance, etc. info
Right now I'm merging the two as best I can, layering 2) over 1) by
means of these pop-ups. I've struggled with the same issue when I do
searches. For example, if I do a search for 'nsString' I can show you
the type info, places where it's used (statements), the string itself in
source (e.g., what mxr does).
How should I deal with these two worlds? You're going to want to flow
between them pretty easily, but sometimes concentrate on one or the other.
I figured you could probably categorize the results:
TYPES:
<a href="link-to-typeinfo">nsString</a> (<a
href="link-to-declaration">source</a>)
...
USED AT:
links to source code locations...
I tried something like this, throwing files and types into side panels,
for example, a search on nsString:
http://zenit.senecac.on.ca/wiki/dxr/search2.cgi?ui=off&string=nsstring
Google does a bit of this too sometimes, with other results at the top,
and sometimes some other searches you can click at the bottom. I also
think parts of the WolframAlpha interface are interesting, too. For
example, searching for a type name and getting an inheritance graph,
member info, some users, raw string search. I think this is something
we'll have to try and improve as we see it and can play with it.
What I'd really like is an inheritance diagram, much like the ones I made
for nsAString. Otherwise I recommend only listing the direct base, not
any
"grand-bases".
For every base type, I record all concrete types, and I know if each is
direct or not. In other words, I can build a tree like you want, if I
do a recursive set of selects.
I'm not sure I want to pay for this every time I get type info, so what
if I do a dynamic tree, where you see direct bases, but can expand each
one to get its bases (and maybe its other derived types too?).
No, I agree that the full diagram each time is probably overkill. Although
I'm hoping we can still end up statically creating most of this so it
doesn't involve a lot of webserver work to fetch it.
Do you have "drawing" code I could use for producing these statically?
I'd do it from python + db vs. dehydra directly. I hadn't thought of
producing them statically, but that would be pretty easy, and could be
part of the same script I use to generate the html.
* When clicking on a macro, it's important to say where it was defined.
I wish I kept irc logs! When I complained at the size of the macros
info I generated with loc info, *you* told me that you didn't care where
a macro came from as long as you knew its value. The trouble with
keeping track of where things come from is that I'll get a crazy amount
of repetition, bloating the db, making lookups slower.
Argh, if I said that I am truly sorry!
The use-case I'm trying to solve is: I see NS_ENSURE_SUCCESS in the code.
Clicking on it tells me the full macro expansion, but doesn't tell much
about why I would use it. Linking back to the original location lets me see
the surrounding header.
Does the DB store each instance of the macro separately? I figured it would
just map NS_ENSURE_SUCCESS to a location once, or at most a few times if
there are multiple macro definitions.
You can probably tell me a better way to do this, but here's what I'm
doing now:
make -f client.mk build REPORT_BUILD='$(if $(filter %.cpp,$<),$(CXX) -dM
-E $(COMPILE_CXXFLAGS) $< > $(subst .o,.macros,$@) 2>&1,@echo $(notdir
$<))' > /dev/null 2>&1
So now for every .cpp it builds, it first creates a .macro file. For
every macro in the current translation unit, I'll get lines like this:
#define SCOPE_MAKE_UNIQUE_SHAPE(cx,scope) ((scope)->shape =
js_GenerateShape((cx), JS_FALSE, NULL))\n
Notice I have no loc info at all. I don't even know which file it's
from--it could be from any include in the current file. So I take all
these .macro files, combine them and remove duplicates, then throw them
in the database.
To get you loc info, I need a new technique, I think. Or some knowledge
I don't have.
This seems to be the result of prtypes.h being copied vs. symlinked into
dist/sdk/include like other things in there. Why is that? Same issue
for things in dist/sdk/include/obsolete/protypes.h.
This is because we call NSPR `make install` to install those headers. I can
look to see if there's a hack which would cause them to be symlinked.
Great, let me know if you think of something. I can always manually fix
this after the build completes (like I do for .h files in dist/include/nss).
Thanks again for the feedback and interest.
Dave
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
