Does it give you an error message? For me, running make in that directory
now only builds the test outputs, it doesn't actually run the tests. For
that you need to run make test from the top-level directory.
Btw, `make` in the test dir never ran tests AFAIK:
Ah, you know what I forgot? I should say Go do `python setup.py develop` (if
you want to hack on it) or `python setup.py install` before doing anything.
somewhere. On the Vagrant VM, which is where I do my work, I've rigged that to
happen automatically. Sorry!
Btw, installing the package as
I should say Go do `python setup.py develop` (if you want to hack on it) or
`python setup.py install` before doing anything. somewhere.
Done. Feel free to submit pulls to improve clarity.
https://github.com/mozilla/dxr/commit/e0a3b50d7ea0cfa55c73dcb0a7eb5112bedb5e40
I'm working off the testing branch, pulled yesterday, and when I try to
build it complains and tells me that there is no depend target. That's a
lie, of course, because I use the depend target often in my make system, so
obviously dxr-build is not finding the makefile properly.
If this does
That's what's strange...git status doesn't complain about the plugins
directory in the old location. In fact, I can do a git log in that
directory and get stuff from as recently as Jan 15.
My mistake. My guess is that git, which tracks only files, doesn't bother with
that plugins dir if it
I guess the take-away lesson is that when doing a re-org of the tree, there
needs to be some out-of-band way to communicate to anyone who may have a
clone to perform a clean.
I'll be sure to post about that and stick it in the (coming soon) changelog in
the future. Sorry to had to chase
Thanks Erik
No problem! Ah, and the + in front of some of those queries means use the
fully qualified name, and require an exact match. (Thanks, abbeyj.)
Erik
___
dev-static-analysis mailing list
dev-static-analysis@lists.mozilla.org
I should also mention that we're thinking about not having contains searches
happen by default: https://github.com/mozilla/dxr/pull/104
___
dev-static-analysis mailing list
dev-static-analysis@lists.mozilla.org
I have a Firefox keyword for searching with old DXR. Is there a hope we
can enter search criteria directly in the url?
I don't see why not. Hit Return in the search field, and you'll get a URL like
this:
http://33.33.33.77:8000/search?tree=codeq=readmeredirect=true
You could easily sub
I know you got this fixed, but here's my guess at what happened for the benefit
of future victims. Puppet provisioning probably timed out while downloading
LLVM and clang. You would have seen a subtle error report about this when doing
vagrant up. Unfortunately, Puppet doesn't stop on error, as
The text search in MXR does a contain search by default, and the identifier
search does an exact match. I would try to match that.
There could be a syntax for exact match, like foo
Good news: abbeyj fixed this last week, though it isn't deployed yet:
https://github.com/mozilla/dxr/pull/104.
I am not an idiot, but assume that for anything related to python I am
ignorant but read well.
I love this sentence and might use it in the future. :-)
So, I get to the point of doing python setup.py develop, and it chugs
along, then stops trying to download Flask. Specifically, I get the
Doing the pip first worked, though I had to lengthen the timeout delay. This
machine sits behind a firewall that actually downloads everything on your
behalf first, then scans it for viruses/issues, then returns it to you if it
passes all checks.
Ooo, fancy-pants. :-)
Rebuild worked
To be clear, the only thing I need to do is run dxr-serve.py, e.g.,
$ dxr-serve.py
??
dxr-serve.py target
(where target is the folder spat out by dxr-build)
All the commands have good help now: you can just pass them --help.
___
Tried this and it worked. callers:someFunc took, according to the returned
web page Query executed in 225.399s
That's a long time. How can I help you figure out which index (or indices)
are missing? If I remember correctly, that query used to have an obnoxious
number of outer and
In a really old and ancient version of dxr, one could configure it to pull
in changes from version control as part of the build. Is that still in
there somewhere and I'm not seeing it?
This might have been part of DXR itself in the past, though I have no knowledge
of it. Currently, we have a
David,
I am fixing it as we speak! Due to some IT bottlenecks, it's been limping along
on an obsolete version for months now, missing all the good bug fixes and
improvements that have landed on master. We've tried to apply makeshift fixes,
but those have made things worse in some cases. I'm
David et al,
I've completely redone the staging site, http://dxr.allizom.org/ . It should be
useable; please try it out. My next 2 orders of business are to reproduce this
work for the production site, dxr.mozilla.org, and to bring the moz-central
tree up to date—currently, it's serving a
DXR's production site (dxr.mozilla.org) is now running the latest version of
DXR, on a modern bed of pooled WSGI processes. This follows yesterday's update
of the staging site and brings with it 4 months of feature additions and bug
fixes.
Both sites are still using a March 11 version of the
A word of warning about the hg plugin, it includes the log message once for
each line...
This might blow up the HTML file size more than it already is... So you might
want to checkout file size of a big cpp files before you enable this in
production.
Thanks! I think Taras mentioned that
Both sites are still using a March 11 version of the mozilla-central tree
No more! dxr.mozilla.org is now serving a mozilla-central from only 18 hours
ago. I finally got everything building under clang. There is yak hair all over
the place.
Next come automatic updates for both the DXR code
Fixed on master, and my experimental continuous deployment script rolled it out
to dxr.allizom.org. I'm going to do a few more commits to work out any kinks
and then expand it to production.
On Jun 2, 2013, at 2:16 , Jonas Finnemann Jensen jop...@gmail.com wrote:
Looks to me as if the newly
I just finished a set of wireframes rethinking DXR's UI. (This is actually
revision 2; many of you probably didn't see revision 1.) Please take a look and
send feedback!
https://wiki.mozilla.org/DXR_UI_Refresh
Specifically, I'm looking for things that will bother you in your common
workflows.
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
It was fun hanging out at the summit... I like the simplifications, but have
3 quick comments:
1) You forgot the exclusion prefix -, for queries like: -excludedkeyword
-excluded phrase -path:*.cpp
Good catch. Fixed!
2) I saw fully qualified names under To Be Determined I hope you keep
https://blog.mozilla.org/webdev/2014/02/07/dxr-gets-a-huge-ui-refresh/
Happy hacking!
___
dev-static-analysis mailing list
dev-static-analysis@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-static-analysis
that's pretty, but where did the list of classes class members go when
viewing files like
http://dxr.mozilla.org/mozilla-central/source/modules/libjar/nsZipArchive.cpp
Coming back soon: https://bugzilla.mozilla.org/show_bug.cgi?id=965659. We're
having some trouble reducing it to a test
Hi, Reed. Rest assured, many of your wishes are planned for the future. But
when you have a big project, you've got to pick some things.
Last week's release was an important milestone: it was the minimal feature set
that would yield a cohesive experience under a UI new design. The new design
that's pretty, but where did the list of classes class members go when
viewing files like
http://dxr.mozilla.org/mozilla-central/source/modules/libjar/nsZipArchive.cpp
I believe this is fixed now, a casualty of a needless use of JS, which is now
gone. If you still see this behavior, please
We've just added comm-central to DXR!
You can find it at http://dxr.mozilla.org/comm-central/source/ or through the
new Switch Tree menu. The menu knows some tricks: it tries hard to preserve
things like your browsing position and your search query while moving from tree
to tree, so you can
Thanks to contributor Jamon Camisso, multi-line highlighting has just landed in
DXR. Now you can do things like this...
http://dxr.mozilla.org/mozilla-central/source/CLOBBER#10-15,18-22,4-5
...by pressing buttons like this:
http://dxr.readthedocs.org/en/latest/code-highlighter.html
Thanks, everyone! One further question, is there anything preventing us from
working with the current clang ToT? Have there been severe API changes since
we wrote this code?
The best way to know is to try. :-) Clang's C++ API changes from minor version
to minor version. We've had to add
From the Killed, it looks like you're running out of memory and the OS has
started killing off processes to keep things afloat. The set of measurements
at the bottom of your transcript shows only 33% memory use, but I wonder if I
could get a second opinion: what does vmstat -S m -a say on the
Marcell has been my intern on the DXR project these past months, and it's been
a privilege to work with him. From JavaScript analysis to Elasticsearch to
writing Haskell in Python, he's cut an impressive swath through the codebase,
and you can expect to see a lot of his handiwork deployed in
(per IRC) so that did help, and I uploaded the CSV to a github gist:
https://gist.github.com/rhelmer/c3a2a2defcdb98ed2152
So is this just an insane type?
Absolutely; that is utterly insane. Wow. That's more like a compiler
stress-test than an actual type.
I am not sure if it's a bug... do
We've been working on a browser compatibility data store API [2][3].
To that, we (think we) need to add a linting tool that will use the
compat data store to make a code compatibility report.
The question for this group is - can we get someone who knows static
analysis involved now to
Everything David says is on the level. For analyzing code out in the wild,
esprima might be a good candidate to build on. For analyzing Firefox's internal
JS (which is what we're trying to do in DXR), it's not suitable, since
Spidermonkey went off in all sorts of non-standardized directions,
Hi, Andrew. I haven't seen this one before. Do you have a reasonably powerful
machine? Have you tried vagrant destroy followed by another vagrant up, in
case something went awry during initialization?
If neither of those helps, you could try adding the suggested config directive
to
It looks like finding of overrides of virtual methods is missing from
DXR 2.0. Is this intentional?
Hmm, no. The tests seem to pass
(https://github.com/mozilla/dxr/blob/es/dxr/plugins/clang/tests/test_overrides.py).
Where are you seeing it?
___
:
* Cross-project search
* Arbitrary boolean queries
* Search by color
* JS support
* IDL support
* Useful visualizations
Add it to your Whistler schedule:
http://sched.co/3gWR
Cheers,
Erik Rose
DXR Project Lead
___
dev-static-analysis mailing list
dev
> Is there a way to search using filters AND wild cards in DXR? For example,
> if I wanted to list all the methods defined on
There isn't right now, but it's something we could add. Can you describe the
sorts of tasks you'd use it for?
Cheers,
Erik
41 matches
Mail list logo
