What do you mean by "signed"? To me, signed == gpg-signed. If you mean --signoff, well, that's nothing, because as I said anyone can write "Signed-off-by: Arun Prakash Jana engineerarun@gmail.com" at the end of their commit message. Only the GPG signature is an actual verifiable signature.
if I use gpg-sign, will it force all contributors to sue gpg sign?
No. Each commit or tag can be signed or not signed, signed objects can be good or bad (e.g., signing key expired), but that's a local property, and signing one commit has nothing to do with future ones. As you can see there are already signed commits in jarun/googler's history (those from me), but you have been committing just fine.
--gpg-sign
flag to my git aliases, so why not.)
Hmm, I can't find your key on any keyserver:
> gpg --keyserver hkp://keys.gnupg.net --recv-keys C0A712ED95043DCB
gpg: requesting key 95043DCB from hkp server keys.gnupg.net
gpgkeys: key C0A712ED95043DCB not found on keyserver
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: keyserver communications error: Not found
gpg: keyserver communications error: Bad public key
gpg: keyserver receive failed: Bad public key
Have you uploaded your key to a keyserver?
gpg --keyserver hkp://keys.gnupg.net --recv-keys 95043DCB
gpg: key 95043DCB: "Arun Prakash Jana <engineerarun@gmail.com>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
I'm reworking parser logic right now. Could you please let know what's the point of
if tag == "div":
marker = self.url.find("?q=")
if marker >= 0:
self.url = self.url[marker + 3:]
marker = self.url.find("&sa")
if marker >= 0:
self.url = self.url[:marker]
if self.url != "":
if self.url.find("://", 0, 12) >= 0:
index = len(self.results) + 1
self.results.append(Result(index, self.title,
self.url,
self.text))
else:
skipped += 1
The processing part is introduced in jarun/googler@c0808cf, but the commit message doesn't give any example, and after the modifications self.url
surely won't be a URL anymore, unless you percent decode it, then there's a chance, but I just don't see the point.
As for finding the protocol host separator, could you give me an example of it failing? The check was introduced in jarun/googler@d498c50 by the way, which says "Skip google news and images links", but even without this check Google News and Images results should be filtered out under Google's current layout, because they wouldn't survive our class guards.
Finally, can we just remove the "skipped" thing? First, I've personally never seen an ad in Google's response, even for queries that clearly should serve up ads. I think ads are rendered through Javascript in the browser. Secondly, if "google news and images links" count towards skipped, then "... ads skipped" is obviously not an accurate description. Thirdly, I've never seen "... ads skipped"...
http://www.thingiverse.com/search?q=Raspberry+pi&sa=
. This was the format in which google used to give some result URLs to it's own domains or to nearest eating places, based on your location (tracking :D). However, I believe not to check for the google domain is crude.
hello
and you'll find results from Youtube, Google Maps and Google Images.
g mnr-c g-blk
rather than g
— i.e., the URL post processing code has no effect on that (youtube.com certainly can't be a relative link). When I parse classes appropriately, the result does show up regardless.
Currently parser logic is a mess.
- I'm afraid it's true. The problem is none of the guys who worked on the parser (including me or Narrat) had the time to re-work it. So we built-up on it.
I noticed that some tests can be dropped and some can be made more rigorous
- awesome. We'll figure out regressions, if any, during testing.
No need to profile. Comment out resp_body = gzip.GzipFile
and parser.feed(resp_body)
for no IO and no parsing, and in Zsh
> time ( repeat 10 googler --np hello >/dev/null )
( repeat 10; do; googler --np hello > /dev/null; done; ) 0.60s user 0.20s system 43% cpu 1.865 total
Uncomment resp_body = gzip.GzipFile
for IO but no parsing:
( repeat 10; do; googler --np hello > /dev/null; done; ) 0.70s user 0.22s system 15% cpu 5.780 total
Now uncomment parser.feed(resp_body)
for IO and parsing (this is from my new parser logic branch, which even has slightly more overhead):
( repeat 10; do; googler --np hello > /dev/null; done; ) 0.97s user 0.22s system 20% cpu 5.760 total
As you can see, parsing time is negligible; IO is not.
Note that I'm on Wi-Fi right now; might be better on Ethernet. But it's by no means slow Wi-Fi. According to speedtest-cli: latency 4.856 ms, Download: 189.38 Mbit/s, Upload: 165.39 Mbit/s.