Linux code search | Hacker News Reader

Linux code search

codesear.ch

51 pointsadulau41 comments

The about page is worth a look. Some cool stuff going on.

See also my project, http://livegrep.com, which is very similar but does support regular expressions (and feels much snappier on the frontend to me, although his does claim comparable backend times).

Oh... this is going to be confusing :)

There is also http://searchco.de.

I thought I would mention it here as nothing I submit ever hits the front page that searchco.de has just surpassed koders.com in number of lines of code indexed, or rather will have in about 2 hours when the indexing is finished and indices swapped over. EDIT - Now live.

I will have an official announcement once I get the exact count, but its something like 3,338,449,289 lines to 3,800,000,000 or so.

I was thinking the same thing as mikegirouard, about the filename column having links too. I was also thinking I need to learn a bit about JS.

So heres a bookmark to add links to the page, run it after completing the search query: http://pastebin.com/G53SjNWy

Also, its my first little foray into JS, so I'd really appreciate any criticism of the code and/or style.

edit: new link preserves the <td> tags

I love searching code bases for curse words. Lots of humor shows up.

Searching for security vulnerabilities is even more humorous. :-)

I had so much fun demo'ing that ability at a PHP conference one year.

Try curse words such as 'fuck' 'shit ', 'bitch' or 'bastard' :)

I also recommend 'penguin'

'elegant' also provides interesting results

They seem to have removed most of the profanities since last time I checked. Linux is officially boring now :(

Hmm, "hack" seems to return a few results...

"wtf" is interesting.

Interesting tool. Makes me think of a minimal OpenGrok.

I wish that the `filename` column was a link to the raw file (or a link to the file in git.kernel.org).

I agree, that should be the case. Otherwise I have to open the file myself to get the context. And when I do that then I can also directly do the grep on the console.

At which point do we get a search that syntactically understands what its searching? Thats such an obvious improvement when you know that your entire data set conforms to a language that an 80s C compiler can understand.

A simple grep I can do myself (with the added bonus of knowing what version/commit I'm searching against).

How would syntactic awareness change search results? Would we have to change the UI as well, move away from 'type in a string'?

You could weigh search results. Instead of a random comment in a random device driver as to why we use mmap here, you could directly show me the core mmap implementation when I search for it. You can directly link me to functions, you can show me the definition for a struct object inline, you can show me dependency graphs.

Ok yeah, that's more of a code browser than just search.

Would you have an example of a tool which you could use to inspect source code to give this output? I imagine a general lexer or some description would be great for this as you could identify functions, comments, classes etc... and use that to add weights.

https://wiki.mozilla.org/DXR would be a starting point.

There's the problem of regular expressions not dealing with matching parentheses, for one. That makes a lot of questions about code hard to express in a regexp, even something as simple as 'find foo(anything) + bar(anything)' is busted. False positives within strings are also an issue.

I did a code search thing, (which I don't claim is anything more than a hack) described over in this HN thread: http://news.ycombinator.com/item?id=4113348 but yes, the syntax wasn't quite 'a string', you'd type the code you're looking for with parts wildcarded, but parentheses in what you typed had to match.

That's a good idea. Another use case occurred to me after I wrote my comment: to ignore keywords in comments. Sometimes that can be desirable.

I keep going back lately to Rob Pike's idea that breaking files into lines is not the best approach (http://news.ycombinator.com/item?id=4111667). In that paper he proposes a regular expression for breaking up lines into structured content. But maybe there's another way. Like an ometa grammar? (http://tinlizzie.org/ometa)

Anyways, just a few random thoughts.

Regular expressions are the wrong tool for this job.

For Krugle, we actually parsed the various languages so it actually knew the differences between e.g. definitions, invocations, comments, strings, etc. It affords the capabilities to do all sorts of cool queries and analyses.

We did that with Krugle awhile ago. It's still alive as an enterprise product... http://krugle.com/

FWIW I am the author of this tool, and I would like to add something that understands syntax (I think I could start with indexing the code using ctags or cscope, which is hackish but easy to implement). There's obviously a ton of stuff you could do to improve ranking if you could rank results by whether they're a variable, function, etc.

It seems like it's missing something (I'm comparing the pretty graph of profanity in the kernel[1] with manual searches). Is this only 3.4.4?

[1] - http://www.vidarholen.net/contents/wordcount/

The implementation is neat but it doesn't really seem much faster than LXR, which gives you additional info and context. (http://lxr.linux.no)

I plan to add some of this stuff, I have a lot of the relevant data in the index but it's not hooked up on the frontend yet.

All occurrences of the string "lenght" are inside of comments. Phew.

They do POST or perhaps ajax, which means you can't take a link to search results, which means it's useless.

This is weak.

P.S. Chrome source search does the same thing, makes me angry and sad with so many stupid people.

Hi,

I'm the author of this and didn't really intend for it to get submitted to hacker news at this point, which is why it's missing this feature among others. I literally just got things working on Sunday afternoon. I am definitely going to make it possible to link to search results.

Thanks!

That is just insanely fast. OP are you author?

Agreed it is very fast but I believe it is only searching against 3.4.4?

Their about page [0] suggests it is just 3.4.4. Still pretty impressive though :)

[0] http://codesear.ch/about

I'm the author of this. I think I can index a lot more source code and still keep the speed. The important part of the index, the ngrams table, is only 400M or so of space and compresses pretty well. I had a test index at one point that was also indexing all of the C code in these projects:

clang-3.1.src gcc-4.7.1 ghc-7.4.1 linux-3.4.4 llvm-3.1.src lua-5.2.0 openjdk perl-5.16.0 php-5.4.4 Python-2.7.3 Python-3.2.3 ruby-1.9.3-p194

And it only increased the size of the index by about 50%.

You can actually run essentially the same thing over your own code with http://code.google.com/p/codesearch (written by the author of the article codesear.ch is based off).

It's not that fast. With a hot cache "grep -rn mmap /usr/src/linux/" runs in 0.3s on my desktop machine.

EDIT: Don't get me wrong, the code behind this is awesome. I just can't help but think there could be something bigger to search, that is infeasible to do on my desktop. What about all of the code from the Debian repositories or something?

This doesn't require the working set to be in memory (in fact, the size of the index is larger than the amount of memory that I have on the machine).

This is AWESOME!

Reply on news.ycombinator.com