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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
Walker was being moved for each iteration and this was being a problem
for proper `Entry` matching.
Removes `Item` indirection and `continue_walk(self, ...)` is now
`inspect(&mut self, ...)`.
This patch changes the warp filter boxing strategy so, that:
1. paths are nested with a "prefix" matcher, if possible
2. the actual handler for the matched path is boxed
3. the non implemented but recognized paths are unified
This strategy might be a good compromise between optimizations and
compilation time but such measurements are yet to be done.
Previous boxing strategy ended up being quite unfortunate. Upon adding
the full `/add` implementation, the test cases using GNU binutils linker
or ld 2.33 (ubuntu) started failing failing with a thread overflowing
its stack.
Most of the stack frames were warp filters for matching the path. This
happened because the combine! macro used in http/src/v0.rs boxed
(mostly) each filter, meaning the compiler could never see through any
of the and requiring enough many frames at runtime to cause a stack
overflow.
An alternative of opt-level = 1 turned out to be easy and simple and was
explored in #293 while this solution was being searched for. The
downside is increased compilation time.
not sure how much sense does this make, given that the byte writing fns
might be less inlined. would be nice to have some benchmarks.
this also adds a test to verify directory cid when using cidv1 even
though it's quite unclear to me if those are allowed in unixfs dirs.
use the BTreeMap<String, Leaf> directly to output the PBLink alike
bytes without going through the mapping into Vec. Does not support Cid
v1 though yet.
adds the progress reporting, which is a progress notification to the
response stream on every block write *in addition to* a notification
*after* the file has been read (order with the `Added` message doesn't
seem to have been specified).
