Update to 0.4.0-dev spec #1
5b690f1b11
to 49290349dd
I just heard back from the hashfs users that they are migrating away from hashfs. :|
Oops, sorry for closing. Clicked the wrong button by mistake.
Some more changes coming to 0.4.0 so I suggest keeping this open until 0.4.0 drops.
Just saw that python-eris now has two implementations of the encoding! :)
Pushed another update of the implementation at eris/encode.py: 484f0d55d7
Working on a decoder now.
I've moved the hashlib interface to eris/encode.py: a5bd0d2a80, added one more change from erisx3 and merged to main.
I'm sorry to have dropped your very neat implementation in hashlib_extension.py for the more verbose one in eris/encode.py. For anybody interested, it's very concise (less than 100 lines of code) and re-uses the first part of the buffer for constructing internal nodes: https://codeberg.org/eris/python-eris/src/branch/erisx3/eris/hashlib_extension.py. I don't think the re-use of the buffer improves performance in Python, as Python bytes are immutable. But it's a neat trick that should be used in a C (and C-esque languages) implementation.
Since hashfs users are migrating away from hashfs I've also droped the hashfs tests.
Deduping the encoders is fine by me, that method came from the Squeak implementation and now it's the one I'm able to keep in my mind. I did have difficulty working with Python buffers so I can imagine it's not ideal.
If that is the most compact algorithm we can find then I can describe it in the spec, either as pseudocode or in an appendix.
Pull request closed
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?