Bump to random-access-storage 3.0.0 and other deps #100
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bltavares
added a commit
to bltavares/flat-tree
that referenced
this pull request
Feb 23, 2020
On [random-access-storage](https://github.com/datrs/random-access-storage) issue datrs/random-access-storage#6 has changed all types from `usize` into `u64` to be able to handle more than 4gbs on 32bits systems. > usize is 32 bits on a 32 bit system, so the storage would be limited to 4GB on such a system. When changing `random-access-storage` on `hypercore` (tracking: datrs/hypercore#100) one of the things I've noticed is that it wold be easier to also make `flat-tree` use `u64` to integrate with `random-access-storage`. Very likely, this also means that we would need to bump to use more than 32Gb storages on `flat-tree`. I've simply changed all declarations of usize into u64. All tests are passing.
bltavares
added a commit
to bltavares/merkle-tree-stream
that referenced
this pull request
Feb 24, 2020
On [random-access-storage](https://github.com/datrs/random-access-storage) issue datrs/random-access-storage#6 has changed all types from `usize` into `u64` to be able to handle more than 4gbs on 32bits systems. > usize is 32 bits on a 32 bit system, so the storage would be limited to 4GB on such a system. When changing `random-access-storage` on `hypercore` (tracking: datrs/hypercore#100) one of the things I've noticed is that it wold be easier to also make `merkle-tree-stream` use `u64` to integrate with `random-access-storage`. Very likely, this also means that we would need to bump to use more than 32Gb storages on `merkle-tree-stream`. I've simply changed all declarations of usize into u64. All tests are passing. Needs: --- - [ ] datrs/flat-tree#44
4 tasks
|
@khernyo @substack Hi there, sorry to bother. I'm in the middle of the upgrade to random-access-storage using the new API using u64 instead of usizes, and I'm not sure if I'm doing it right. I'm reflecting the changes on the other libraries ( Should I avoid changing the other libs and just keep the casts on hypercore instead? I'll wait a bit on changing the other libs until I have some feedback here. |
bltavares
added a commit
to bltavares/tree-index
that referenced
this pull request
Feb 24, 2020
On [random-access-storage](https://github.com/datrs/random-access-storage) issue datrs/random-access-storage#6 has changed all types from `usize` into `u64` to be able to handle more than 4gbs on 32bits systems. > usize is 32 bits on a 32 bit system, so the storage would be limited to 4GB on such a system. When changing `random-access-storage` on `hypercore` (tracking: datrs/hypercore#100) one of the things I've noticed is that it wold be easier to also make `tree-index` use `u64` to integrate with `random-access-storage`. Very likely, this also means that we would need to bump to use more than 32Gb storages on `tree-index`. I've simply changed all declarations of usize into u64. All tests are passing. It also fixes Travis CI and update libraries to latest version. Needs: --- - [ ] datrs/flat-tree#44
4 tasks
This commit compiles `hypercore` using the new u64 crates: - random-access-storage - random-access-disk - random-access-memmory - merkle-tree-stream - flat-tree - index-tree
|
I've got it to compile with the extra crates (except for bitfield) changed from I'm not sure how correct things are, and if the other crates also need to change, but it compiles now, and the tests passes. If someone could review it, and the other PRs on the other crates (specially if they are necessary), I would love that. |
|
Given that the API takes slices, I think it will also be limited by 32bits systems as well, from what I understood. Maybe it would be nice to ship the new version and have a setup test on a 32bit platform to find errors. What are relevant 32-bits platforms to keep testing? (Given that apple 32-bits has been lowered to second-tier) |
This was referenced Feb 26, 2020
yoshuawuyts
pushed a commit
to datrs/merkle-tree-stream
that referenced
this pull request
Mar 2, 2020
* Change from usize to u64 On [random-access-storage](https://github.com/datrs/random-access-storage) issue datrs/random-access-storage#6 has changed all types from `usize` into `u64` to be able to handle more than 4gbs on 32bits systems. > usize is 32 bits on a 32 bit system, so the storage would be limited to 4GB on such a system. When changing `random-access-storage` on `hypercore` (tracking: datrs/hypercore#100) one of the things I've noticed is that it wold be easier to also make `merkle-tree-stream` use `u64` to integrate with `random-access-storage`. Very likely, this also means that we would need to bump to use more than 32Gb storages on `merkle-tree-stream`. I've simply changed all declarations of usize into u64. All tests are passing. Needs: --- - [ ] datrs/flat-tree#44 * Fix travis
yoshuawuyts
approved these changes
Mar 2, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are lots of things that will break.
Needs
Choose one: a 🙋 feature
Checklist
Context
Updating
random-access-storageto the latest version requires a lot of changes, as it changes the api from usize's to u64'sSemver Changes
minor (breaking, but below 1.0.0)