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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
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).
this is the go-ipfs 0.5 level support for add and directories. next up
will be parsing the headers as unixfsv1.5 metadata and using those with
the directories *and* files.
290: Some maintenance r=koivunej a=ljedrz
Some maintenance work so as not to conflict too much with the pending PRs:
- depend on cid instead of libipld where only Cid is used
- update the `domain` dep (big `Cargo.lock` wins)
cc #75
Co-authored-by: ljedrz <ljedrz@gmail.com>
272: Split Entry into two different enums to remove unnecessary expects r=koivunej a=c410-f3r
Second take on #200
`Entry` is now composed of `Bucket(...)` and `Metadata(MetadataEntry { ... })` to separate things that have and doesn't have metadata, which avoids returning optional values derived from a single entry-point.
Next PR will address the newly introduced double matching while iterating over `continue_walk` but it will require deeper logical changes.
Co-authored-by: Caio <c410.f3r@gmail.com>
267: ci: use vcpkg for openssl on windows r=ljedrz a=koivunej
Hoping to find something to help with #261:
- switch to using [lukka/run-vcpkg](https://github.com/lukka/run-vcpkg)
- get rid of the llvm dependency on windows (it was not needed)
- update openssl dep to 0.10.30
Co-authored-by: Joonas Koivunen <joonas@equilibrium.co>
259: Multihash-based repo r=koivunej a=ljedrz
We currently have an ad-hoc `Cid`-upgrading mechanism in place for the legacy `v0` version that is complicated and error-prone; when working on the `SubscriptionRegistry` I had to disable some of those upgrades, but some of them were still applied in the `Repo` (and necessary in order for the conformance tests to pass), making it hard to work on further functionalities like content discovery.
The solution I came up with is to introduce a `RepoCid` wrapper in order to make the keys in `Repo` objects operate on the associated `Multihash` instead of the whole `Cid`. Changing them to plain `Multihash`es wouldn't work, as we are still expected to return `Cid`s for the purposes of e.g. `Ipfs::local_refs` and I'm pretty sure some of the conformance tests still expect the full `Cid` to be available.
The only drawback is some extra `clone()`ing, but the improvement in code clarity and the unblocking of further changes is well worth it. This change also simplifies one of our conformance test patches (local refs).
~~I'm marking this PR as a draft in hopes that I can still come up with some solution to the extra cloning.~~ This is hard; I'm not able to do this at the moment, but this shouldn't be a blocker.
Co-authored-by: ljedrz <ljedrz@gmail.com>
