-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Cleanup] Initial documentation improvements and code cleanup #8
Conversation
Reviewpad Report (Reviewpad ran in dry-run mode because configuration has changed) 📜 Executed actions $removeLabel("small")
$removeLabel("medium")
$addLabel("large")
$removeLabel("documentation")
$removeLabel("dependencies") |
…t until package is on OSS-Fuzz
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #8 +/- ##
=======================================
Coverage 84.53% 84.53%
=======================================
Files 8 8
Lines 776 776
=======================================
Hits 656 656
Misses 85 85
Partials 35 35
☔ View full report in Codecov by Sentry. |
@@ -12,6 +12,7 @@ const ( | |||
var ( | |||
defaultValue []byte = nil | |||
|
|||
// ErrKeyNotPresent is returned when a key is not present in the tree. | |||
ErrKeyNotPresent = errors.New("key already empty") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like "key already empty" should be an error for trying to delete an unavailable leaf. ErrKeyNotPresent
could also be used when we try to retrieve something non-existent, so it feels like we're conflating a couple things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this error is actually only used in the Delete
function as if we try to get a key that's not set it returns an empty value - bc all keys are technically set but most are just empty.
@@ -6,8 +6,8 @@ import ( | |||
) | |||
|
|||
var ( | |||
_ treeNode = &innerNode{} | |||
_ treeNode = &leafNode{} | |||
_ treeNode = (*innerNode)(nil) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this a recommendation of the linter?
I'm personally a bigger fan of the previous approach, or potentially using var _ treeNode = new(innerNode)
instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually thought about this a lot and went into the golang discord and this is the idiomatic go way to do this.
There is potentially some issues around the other way linked here but it is unclear if this affects this specific use case.
Co-authored-by: Daniel Olshansky <[email protected]>
Co-authored-by: Daniel Olshansky <[email protected]>
Co-authored-by: Daniel Olshansky <[email protected]>
Co-authored-by: Daniel Olshansky <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's keep iterating (merkle sum, radix tree, visualization tooling etc...) and improving the docs, but this, as is, is already really solid work.
Here's to moving the industry forward 🥂
@@ -0,0 +1,65 @@ | |||
<!-- REMOVE this comment block after following the instructions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realize the urge to throw small things like this into larger PRs, but do try to separate it in the future. nbd this time
|
||
The different nodes types described above make the tree have a structure similar to the following: | ||
|
||
```mermaid |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you made really good progress on this, but there is still a lot of opportunity to improve it so it's easier for the reader to understand & interpret. Similar to what the JMT and Relay Mining Paper do. For example, by showing (k, v) = (a, b)
or path=0b001
or path_bounds=...
.
In either case, the visualizer we build might do this automatically for us in the future (we can just have a python structure to mermaid converter) so not a blocker for now.
https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf
https://arxiv.org/pdf/2305.10672.pdf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added an interim diagram before we can have a more detailed one to show the paths of different nodes
|
||
_Note_: This diagram is not entirely accurate regarding the process of creating a leaf node, but is a good representation of the process. | ||
|
||
```mermaid |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing diagram! 👏
Co-authored-by: Daniel Olshansky <[email protected]>
Overview
This PR addresses the lack of documentation in the repo by adding some details to the
README.md
file and adds some more godoc comments throughout the codebase.The workflow files have been updated to a use go version 1.18 and have been updated to fully test the repo and produce code coverage reports and check against linters.
The legacy fuzzing has been removed and instead now uses go native fuzzing, the fuzzing tests remain the same and can be improved upon in a separate PR. The oss-fuzz build script has been removed until this repo is on oss-fuzz a new script will not be made.
Additionally linter errors have been addressed.
Issue
Fixes #7
Additional testing enhancements will be covered in a separate PR
Checklist