implement CidFromReader #127
Conversation
This comment has been minimized.
This comment has been minimized.
|
Not super helpful that codecov is complaining about every uncovered line... I'd need to spend another 4h on this to get 100% coverage, and it feels somewhat futile. |
There was a problem hiding this comment.
👌 very nice
Out of interest - is this style of return: (int, foo, error) where int is always meaningful even if error is non-nil an idiomatic Go thing? Would a user naturally assume that the first return value shouldn't be ignored in a non-fatal error? It's good that this is mentioned in the doc at least and I don't suppose there another way around this without a more sophisticated reader interface (like a pushback).
|
I'd love to have some tests that check that all the byte buffering dancing is correct. (It looks correct, but I've stopped trusting my eyes and mental model of the compiler completely in things as fiddly as this.)
Either would be good. The latter is more fragile and gives less holistic impact numbers, but also results in something that can actually go red/green in CI rather than requiring someone to keep an eyeball on things, so both have different kinds of value. I don't know if I consider this a blocking request or not, though. If it's already been profiled from some place where it's being used, I'll believe it's correct. Having tests or benchmarks in the same repo will just make it easier to be sure we don't ever regress it. |
|
Interface LGTM, anyway. Returning an int like this to report partial progress in I/O reading is golang normative, yes. It describes a side effect that you couldn't otherwise get much insight into, and while that data's not always needed, when it is, you really need it, so it's good practice to always return it. |
This PR is pure functionality, not optimization/performance. It's virtually impossible to accomplish this without CidFromReader today, unless you're happy with reading a "probably large enough" chunk of bytes and hoping for the best. In that way, I don't think performance should block this PR. I agree benchmarks and profiling would be nice, but that seems like it should come after. All I can say on the matter is that our use in carv2 works, and seems fast enough :) I admit I didn't go out of my way to write more tests to try to get 100% test coverage on this func. I'll see if I can reuse |
|
The leading varint simplification that Steven suggested is now done.
That's now done too. |
And reuse two CidFromBytes tests for it, which includes both CIDv0 and CIDv1 cases as inputs, as well as some inputs that should error. Fixes #126.
|
@Stebalien the two byte slice comments are addressed, and the two perf nits now have TODOs. Want to take one last look? |
(see commit message)