Thu, 16 Feb 2023 18:46:44 +0000 rhg: use generic DestArr in hash_mangle
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 18:46:44 +0000] rev 50211
rhg: use generic DestArr in hash_mangle This simplifies code a bit more, but comes with an extra memory copy in case [destlen == dest_vec.len()]. This is probably fine, but a follow-up change is removing that too.
Thu, 16 Feb 2023 18:45:23 +0000 rhg: in path_encode, make DestArr generic over its size
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 18:45:23 +0000] rev 50210
rhg: in path_encode, make DestArr generic over its size
Thu, 16 Feb 2023 18:41:06 +0000 rhg: in path_encode add a DestArr type
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 18:41:06 +0000] rev 50209
rhg: in path_encode add a DestArr type This is an implementation of Sink trait that writes into a fixed-size buffer on the stack, so identical to what was done before, but it makes the code of [hash_encode] easier to understand by dropping all these slice manipulations.
Thu, 16 Feb 2023 18:29:52 +0000 rhg: reduce verbosity in path_encode by using a trait for writing
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 18:29:52 +0000] rev 50208
rhg: reduce verbosity in path_encode by using a trait for writing Hopefully this makes the code easier to read and understand and shorter overall. It also lets us later tweak the type we use as a [Sink], without having to change the encoding functions, including using two different types for size measurement and for the actual serialization.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 tip