![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
One:
Well, actually, thanks to Dijkstra. What's really crazy is this: what if I hadn't happened to read that article? Then would I be doing bounds wrong? Or would I have figured it out anyway? And how many other things have I been doing wrong because I didn't read the right Dijkstra article?
Two:
PCRE: "
Sure, because 2GB should be enough for anyone. It's not like there is a special data type designed explicitly for representing the size of data in memory that is no harder to use than integer.
Oh, look, here's the issue biting someone. (My comment on that bug is not correct; there is a workaround possible. But it will still be a big hassle).
Three:
I added a bunch of code to ag (a replacement for ack). Unfortunately, due to the bug fixes I made, it is no longer faster than ack. Which I guess should not be all that surprising; Perl's regexp engine is pretty well tuned, and most of the time will be spent in regexps or system calls, so there's no strong reason for a C reimplementation to be dramatically faster. On the other hand, ag is now handling gitignore files (and hgignore, etc) more correctly (this is the cause of the slowdown); ack doesn't even bother to try. So, I guess I'll stick with ag for now.
Time periods: When searching, the time periods now have their upper bound excluded. It will allow us to have a cleaner or more correct dataset. API doc. Credits go to @NovalisDMT for spotting the problem.
Well, actually, thanks to Dijkstra. What's really crazy is this: what if I hadn't happened to read that article? Then would I be doing bounds wrong? Or would I have figured it out anyway? And how many other things have I been doing wrong because I didn't read the right Dijkstra article?
Two:
PCRE: "
The maximum length of a subject string is the largest positive number that an integer variable can hold."
Sure, because 2GB should be enough for anyone. It's not like there is a special data type designed explicitly for representing the size of data in memory that is no harder to use than integer.
Oh, look, here's the issue biting someone. (My comment on that bug is not correct; there is a workaround possible. But it will still be a big hassle).
Three:
I added a bunch of code to ag (a replacement for ack). Unfortunately, due to the bug fixes I made, it is no longer faster than ack. Which I guess should not be all that surprising; Perl's regexp engine is pretty well tuned, and most of the time will be spent in regexps or system calls, so there's no strong reason for a C reimplementation to be dramatically faster. On the other hand, ag is now handling gitignore files (and hgignore, etc) more correctly (this is the cause of the slowdown); ack doesn't even bother to try. So, I guess I'll stick with ag for now.