- User Since
- Jan 11 2018, 4:59 AM (130 w, 2 d)
Feb 24 2020
Feb 18 2020
Feb 14 2020
Feb 13 2020
Feb 12 2020
Feb 10 2020
Thanks for the heads up. I'll try to dedup them.
Jan 24 2020
Jan 17 2020
Jan 16 2020
While I think the rust regex crate is heavily inspired by RE2 and uses a fairly compatible syntax I don't think there is a goal to be 100% compatible and I would be surprised if there weren't any differences. What I am trying to say is that if we are going to change engines we may as well change to regex. If we are using RE2 for backwards compatibility then this change makes sense.
Does mercurial currently use RE2? If not then can you explain why we don't just use the rust regex crate?
Maybe what we should do is keep the test I proposed, but change the definition of BLOCK_SIZE to be based upon the number of contained i32 instead of size_of.
Ah yes. So my test would be ineffective.
I think it's better. Maybe still a little vauge but I'll let subject experts make that decision.
One last note is why not just put this in HgPath?
Jan 15 2020
I'm not convinced PrettyPrint is the best name. I might call it something more to do with escaping instead of "pretty". However I can't think of anything great.
Dec 11 2019
Dec 9 2019
Dec 2 2019
Nov 7 2019
Nov 6 2019
Oct 30 2019
I see a lot of the functions are here to give optimization hints. In order to make someone non-familiar with the code able to understand it each method should state the contracts that it is making. I am having a really hard time reconciling how the different functions interact and which methods have precedence over each other.
Oct 19 2019
Oct 16 2019
I've seen very good results with https://github.com/servo/rust-fnv in the past so it is probably worth including that in the comparison and possibly using it. It is especially good for small keys which seems like a common case in hg.
Oct 15 2019
Thanks, looks good.
Sep 13 2019
Sep 12 2019
Aug 30 2019
It looks good overall. I just would like to have a bit more strict definition of what an HgPath can contain and preferably some init-time validation.