31–40 of 47 posts
Earlier quoted context omitted.
http://googlesystem.blogspot.com/2012/01/google-code-search-... —» http://code.google.com/codesearch
In the long term, this will be search only over code.google.com projects, as mentioned in the 'discussion' link on codesearch.google.com.
Interesting solution. I did something a little different for searchco.de when I was implementing regex search. Essentially I took the regex such as [cb]at and then expand it out to get all of the terms, in this case cat and bat and then do a standard fulltex search based on those terms to get as close a match as possible. I then loop over the results to get back those which are exact matches. Its actually more comple…
What does the wildcard match "foo.*bar" expand to?
How do you handle those pathological cases like "f.*r"?
Interesting solution. I did something a little different for searchco.de when I was implementing regex search. Essentially I took the regex such as [cb]at and then expand it out to get all of the terms, in this case cat and bat and then do a standard fulltex search based on those terms to get as close a match as possible. I then loop over the results to get back those which are exact matches. Its actually more comple…
Interesting. What does the wildcard match "foo.*bar" expand to? How do you handle those pathological cases like "f.*r"? Edit: HN can't displaying the wildcard char. Reformat it.
As for the other case you will naturally find all sorts of things that match. But as with the method in the article the more information you give it the closer a match you will find.
I don't know if the best/worst case is any better then the linked but it does work reasonably well.
Earlier quoted context omitted.
Did it stop working internally? Do Google employees still get to use it?
http://googlesystem.blogspot.com/2012/01/google-code-search-... —» http://code.google.com/codesearch
> Regular expression matches do not always line up nicely on word boundaries, so the inverted index cannot be based on words like in the previous example. Instead, we can use an old information retrieval trick and build an index of n-grams, substrings of length n. This sounds more general than it is. In practice, there are too few distinct 2-grams and too many distinct 4-grams, so 3-grams (trigrams) it is.
As he explains, in order to perform a search using regular expressions, the RE is first converted to an "ordinary" query string, which finds a set of candidate documents; the candidate documents are then loaded in memory, and the "real" regular expression run against them, in order to find only the matching documents.
He used Google's retrieval engine in order to build the trigram index, but he doesn't say how he identified "code" amidst the ocean of ordinary web pages?
He does say this regarding an example implementation:
> The indexer (...) rejects files that are unlikely to be interesting, such as those that (...) have very long lines, or that have a very large number of distinct trigrams.
so maybe that's what Code Search did too.
What I'm wondering is this: wouldn't it be interesting to have a full web index based on trigrams, that would let us search not only using RE but also using wildcards (at the end of words or at the beginning)?
Maybe it would be too complex to build such an index for the whole web, but for limited corpora (such as one's mail) it would be very useful.
Earlier quoted context omitted.
Wow, everyone's a cynic. Did you miss the part about the trigram index? It sounds like you are replying to regexp1.html, not regexp4.html.
No. You misread. I love Russ Cox's way of thinking and his continual generosity in sharing his work. I too use the Plan 9 base sed and grep. I'm cynical about the people who rave on about perl/javascript/python/ruby/whatever regexp, who derive some perverse joy in ridiculously complex RE and who often diss sed and all things old school as being slow or deficient in some way.
Google made a mistake in killing code search. Indexing the world's source code and making it searchable is so obviously part of their core mission that I wonder how this decision even got made. Yeah, code search is a niche market numerically speaking, but intellectually and economically (considering the economic impact of software) it is vital. Google was doing so much better a job of it than anybody else that they c…
You mentioned hoping someone can come along to get this right. I am certainly trying with http://searchco.de/ Its still a long way from being close to Google code search both in terms of code indexed (amending that as I write this) but I hope to get things up-to a par as soon as I possibly can. Symbolhound http://symbolhound.com/ also has a code index that's worth a look too.
Earlier quoted context omitted.
Seems like the default should be linear runtime and you should have to explicitly ask for the richer feature set (and opt into the assertion that you trust the input not to DOS your process). Could easily be added as a modifier (see `man perlre`), but should be implemented as two to enable explicit behavior and toggling the default. Randomly picking the letter N: /(\w+) \1/n # Error: look-behind is incompatible with…
I don't think you need to even go as far as adding a modifier. A smart enough regex engine would know when it could use the linear runtime algorithm, and when it needs to fall back.