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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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).
