I got a tooltip say:
Error: JSON.parse: unexpected character at line 1 column 1 of the JSON data
Update:: Oh ^(.)"(.)"(.)$ works and fast.
31–40 of 165 posts
I got a tooltip say:
Error: JSON.parse: unexpected character at line 1 column 1 of the JSON data
Update:: Oh ^(.)"(.)"(.)$ works and fast.
Already has been publicly contacted by:
- GitHub CTO
- SerpApi CEO
- SourceGraph CEO
Search is hot right now!
Next post from danfox - “how to get 3 job offers in 3 hours”. Already has been publicly contacted by: - GitHub CTO - SerpApi CEO - SourceGraph CEO Search is hot right now!
Next post from danfox - “how to get 3 job offers in 3 hours”. Already has been publicly contacted by: - GitHub CTO - SerpApi CEO - SourceGraph CEO Search is hot right now!
Amazin, why Microsoft hasn't built this for GitHub yet is beyond me. Can it grep on individual repos?
Why would you want to use this tool to grep individual repos? If you know the repo you're interested in, you can just clone it and then grep it locally...?
How did you pick the 500k repositories to index out of the 28 million or so which are public?
It was based on the number of stars/forks and the size of the repository.
Next post from danfox - “how to get 3 job offers in 3 hours”. Already has been publicly contacted by: - GitHub CTO - SerpApi CEO - SourceGraph CEO Search is hot right now!
I'm surprised as well, think why big tech companies didn't have this awesome search already.
(See the "Theory: the search problem" section)
Size: This is only indexing ~500k public repos. A first party solution would be expected to index all of it, public and private.
Indexing speed: This can take up to a few days to index. A first party solution would be expected to have a much lower index latency - seconds to minutes.
Query language: This can (and does) have its own simple query language. A first party solution would need to have support embedded into and not break backwards compatibility with the current query language.
Context-dependence: A first party solution would be expected to index private repos as well, and now the query context (logged in user) becomes another variable in an already multi-variate problem space.
Latency: Gets harder with scale, and a first party solution would likely provide a SLA/SLO around latency.
Access control: Same issue as context-dependence, with private repos being included.
There's also unknown but likely considerations around compliance and internationalization, which are quite tricky problems.
Note - I don't mean for this to be critical of the author at all. This is an awesome and useful tool, with a fantastic UX. I just want to make it clear that search at scale is a lot harder than it seems at first glance, especially as the feature requirements increase.
Amazin, why Microsoft hasn't built this for GitHub yet is beyond me. Can it grep on individual repos?
Why would you want to use this tool to grep individual repos? If you know the repo you're interested in, you can just clone it and then grep it locally...?
Why regex still exists? It is unintuitive, requires mastering an obscure syntax, it is very hard to debug, and very difficult to explain to others how it works. It feels like we are trying to write intermediate code by ourselves, while we should have a human readable language that generates regex.
Do it! You will find that it's very easy, but the result will either be extermely verbose or just like regex. Since most regexes (at least for me) are meant as one-time-use, the extra verboseness has no added benefit. If you have complex needs, you should probably be using something other that regex, anyways.
Yeah, regex can be a bit clunky at times and has a steeper learning curve, but they're pretty industry standard at this point, and portable across languages with a few caveats.
Impressive! Really fast, full featured code search across a huge corpus. 1. How did you build the index? Did you use a GitHub dump of some sort? How often do you refresh it? 2. Is it Elasticsearch or similar or a completely custom engine? 3. What kind of RAM/CPU are you using to power it? 4. Any plans to open source the code or commercialize the technology? I could absolutely imagine paying for a private code search…
Thanks! It's built on top of Solr. It fetches the repos from GitHub - it should pick up any updates to repos within a few days. It's running on a couple servers with 20 cores each, which is not really enough for the traffic it's getting right now.