IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
307: Use tokio instead of async_std r=koivunej a=ljedrz
We already use it in `ipfs-http`, our dependencies either already use it or are compatible with it and it has some nice features that we'd like to use.
Note: the `async` tests now specify `max_threads = 1` in order to make sure the multi-threaded executor is not being lenient about any hidden bugs.
fixes https://github.com/rs-ipfs/rust-ipfs/issues/275
Co-authored-by: ljedrz <ljedrz@gmail.com>
306: Cleanup old unixfs api r=koivunej a=koivunej
This removes the previous API of:
* ipfs::Ipfs::add
* ipfs::ipfs::get
* ipfs::unixfs::File
Rationale for the removal is that ipfs-unixfs (under `unixfs/`, re-exported as `ipfs::unixfs::ll`) provides ability to do the similar use cases more or less. It does not however, provide means to have a nice api and persist stuff in an async way which is something we are lacking at the moment. I will probably file an issue for this API deficiency once I am through this.
Co-authored-by: Joonas Koivunen <joonas@equilibrium.co>
there was a discrepency with the old and new way which took some time to
realize. if this destroys anyones workflow I hope we can find a way to
accomondiate you :)
300: use noise authentication with the XX handshake r=koivunej a=ljedrz
The new `0.23` release of `libp2p` seems to have fixed the `noise` incompatibility issues with `go-ipfs`, so update it, drop `SECIO` and use `noise-xx` instead.
While I've successfully tested this both ways against a `go-ipfs-0.6` node, an extra manual test won't hurt 😉.
fixes https://github.com/rs-ipfs/rust-ipfs/issues/75
fixes https://github.com/rs-ipfs/rust-ipfs/issues/175
Co-authored-by: ljedrz <ljedrz@gmail.com>
304: Work around the rare zero wakers CI failure r=koivunej a=ljedrz
As far as I can tell this only happens to Kademlia queries and thus might be a `libp2p` bug; disable the sanity debug check for them to verify it.
Also, remove an outdated comment as a drive-by.
Co-authored-by: ljedrz <ljedrz@gmail.com>
303: Allow connecting using multiaddr/p2p/peerid r=koivunej a=ljedrz
Also add related tests and tweak `connect_two` tests a bit.
Co-authored-by: ljedrz <ljedrz@gmail.com>
297: impl<T: Clone, E: Clone> Clone for Subscription<T, E> r=koivunej a=ljedrz
My suspects are either the enabled `tracing_subscriber` or the lock over `SubscriptionRegistry` taken in `get_subscriptions`; I've adjusted those and tightened the test's deadlines and wasn't able to trigger the issue while stress-testing. It might not suffice yet, but those changes won't hurt.
Co-authored-by: ljedrz <ljedrz@gmail.com>
296: test duplicate connection attempts r=ljedrz a=ljedrz
While attempting to connect to a pre-connected `Multiaddr` didn't cause issues, duplicate `PeerId` attempts caused a hang.
I started by ensuring that the `PeerId` connection subscriptions are handled in the same manner as the `Multiaddr` ones. This, however, was insufficient. I then moved the creation of connection subscriptions before the connection event was pushed onto the swarm event stack, but it was not enough too. The final measure was to just ignore duplicate connection target attempts, which now doesn't even create a `Subscription`, but just causes the top-level call to return an error.
Co-authored-by: ljedrz <ljedrz@gmail.com>
301: Put "Rust-IPFS contributors" as package authors r=koivunej a=ljedrz
The usual convention for Rust crates that are a collaborative, open source effort is to put `<project> contributors` under the `[package] authors` in the `toml`.
Co-authored-by: ljedrz <ljedrz@gmail.com>
299: fix: go back to std::sync::Mutex r=koivunej a=koivunej
Turns out #174 was wrong, as the alternative required sprinkling block_on which made the whole thing worse. We shouldn't risk a deadlock with the mutex as we are not (can not) holding it across awaits.
Unwrap as we are not expecting subscriptions to panic and poison the mutex.
Co-authored-by: Joonas Koivunen <joonas@equilibrium.co>
the assert while holding the guard poisons the mutex and that causes
drop to panic because of the poisoned mutex, by design; see last
commit. by shortening the scope of the mutex guard we should once again
see more clear build failures :)
Turns out #174 was wrong, as the alternative required sprinkling
block_on which made the whole thing worse. we shouldn't risk a deadlock
with the mutex as we are not (can not) holding it across awaits.
unwrap as we are not expecting subscriptions to panic and poison the
mutex.
295: Merge and adapt the libipld dependency r=koivunej a=ljedrz
Our [libipld](https://crates.io/crates/libipld) dependency has been out of date with _its_ dependencies for a while now and since we don't need to maintain a shadow fork of the entire repo in order to be able to keep up, we might as well merge the bits we need until the upstream repo(s) are updated and we can depend on them directly again.
All the copied (with minor adjustments) code resides in the `ipld` module where the source repo is credited.
Co-authored-by: ljedrz <ljedrz@gmail.com>
286: Ipfs object tweaks r=ljedrz a=ljedrz
Removes `SwarmTypes`, drops the generic from `IpfsOptions`, `RepoOptions` and `SwarmOptions` and simplifies the creation of `Ipfs`/`UnitializedIpfs` via more pattern-matching `move`s.
Rationale: since we already need to specify the type in order to create `IpfsOptions`, we might as well do that directly for `Ipfs` instead, without dragging the generic through all the options that don't even use it (they just carry `PhantomData`).
Co-authored-by: ljedrz <ljedrz@gmail.com>
284: unixfs: feat tree building r=koivunej a=koivunej
Includes a `BufferingTreeBuilder` which kind of follows the js-ipfs implementation: a *complete* tree is built from path segments and later it's converted into a dag-pb by an "iterator" which walks the tree in post order, converting (rendering) the most nested elements first. Communication back to the "parent" is done using a `HashMap<u64, Vec<Option<(String, Cid, usize)>>>` which relies on initial ordering provided by `BufferingTreeBuilder` by using BTreeMap's on each level.
Co-authored-by: Joonas Koivunen <joonas@equilibrium.co>
Co-authored-by: Joonas Koivunen <joonas.koivunen@gmail.com>
