209: add feature guards for unstable features r=yoshuawuyts a=yoshuawuyts
Makes sure unstable features aren't accidentally usable without their corresponding flags. Thanks!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts+github@gmail.com>
167: add io::cursor r=stjepang a=yoshuawuyts
Adds `io::Cursor` and makes it so `io::prelude::*` behaves the way it does in std (so it can actually be implemented - though this might just have been a bug on my side??).
Ref #131. Thanks!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
207: Added the ability to collect a stream of results r=yoshuawuyts a=sunjay
As requested here: https://twitter.com/yoshuawuyts/status/1174026374316773377
The standard library has a very useful implementation of `FromIterator` that takes an iterator of `Result<T, E>` values and is able to produce a value of type `Result<Vec<T>, E>`. I asked for this in `async-std` and @yoshuawuyts recommended that I contribute the impl. It turns out that the implementation in the standard library is even more general than I initially thought. It allows any collection that implements `FromIterator` to be collected from an iterator of `Result<T, E>` values. That means that you can collect into `Result<Vec<T>, E>`, `Result<HashSet<T>, E>`, etc.
I wanted to add a similarly generic impl for this crate so we can also support collecting into any collection that implements `FromStream`.
The implementation for this is based heavily on [what exists in `std`](9150f844e2/src/libcore/result.rs (L1379-L1429)). I made a new `result` module since that's where this impl is in `std`. I still wanted to maintain the conventions of this repo, so I copied the `vec` module that @yoshuawuyts created in #125. Much like in that PR, the new `result` module is private.
There is a doctest in the documentation for `collect` that both teaches that this feature exists and tests that it works in some simple cases.
## Documentation Screenshot
![image](https://user-images.githubusercontent.com/530939/65075935-de89ae00-d965-11e9-9cd6-8b19b694ed3e.png)
Co-authored-by: Sunjay Varma <varma.sunjay@gmail.com>
40: Add initial Fuse implementation for Stream r=yoshuawuyts a=spacejam
@matklad does this address your use case?
Co-authored-by: Tyler Neely <tyler.neely@ferrous-systems.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
205: Implement simple work stealing r=yoshuawuyts a=stjepang
This is our first version of a work-stealing scheduler. We won't stop here, there is still lots of room for improvement.
Co-authored-by: Stjepan Glavina <stjepang@gmail.com>
180: adds stream::fold combinator r=stjepang a=montekki
Fold. Kind of clumsy around the part with the option and moving out of the shared context.
___
Stdlib: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.fold
Ref: #129
Co-authored-by: Fedor Sakharov <fedor.sakharov@gmail.com>
203: expose std::pin r=yoshuawuyts a=yoshuawuyts
This is important when defining / calling futures, so it makes sense for us to also export this.
But also given recent user feedback on the confusion on pinning, I'd like to open up the possibility to experiment with providing better pinning facilities such as [`pin-project`](https://github.com/taiki-e/pin-project) or [`pin_mut`](https://docs.rs/pin-utils/0.1.0-alpha.4/pin_utils/macro.pin_mut.html) behind flags. I'm not sure if we could, or even should. But I want to allow us to have that conversation and test things out (even if it's just in floating patches.)
Thanks!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
190: Clean up the fs module and a few other places r=stjepang a=stjepang
Just a cleanup for various pieces of documentation, mainly around the `lib.rs` docs, the prelude, and the `fs` module. Some small bugs are also fixed along the way.
This PR is the first one in a series of review PRs that I will be submitting before the upcoming 1.0 release.
200: expose IoSlice, IoSliceMut r=stjepang a=yoshuawuyts
Exposes `io::IoSlice` and `io::IoSliceMut`. Given we're returning these from `read_vectored` and `write_vectored` it might make sense to just include them as part of our re-exports. Thanks!
Ref #131.
Co-authored-by: Stjepan Glavina <stjepang@gmail.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
196: Remove more Unpin bounds for Stream::scan r=stjepang a=tirr-c
cc #192. I missed the bounds on `Stream::scan` itself.
Co-authored-by: Wonwoo Choi <chwo9843@gmail.com>
171: Add BufRead::consume r=stjepang a=yoshuawuyts
Ref #131. This implements `BufReader::consume`. Thanks!
Note on `fill_buf`: I couldn't get the `async fn fill_buf()` to work, but tracked progress for it here: https://gist.github.com/yoshuawuyts/09bbdc7823225ca96b5e35cd1da5d581. Got some lifetimes isssues. If anyone wants to give this a shot, please do!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
192: Add Stream::scan r=stjepang a=tirr-c
Ref #129. The mapper function `f` is synchronous and returns bare `Option<B>`.
Asynchronous `f` seems tricky to implement right. It requires the wrapper to be self-referential, as a reference to internal state may be captured by the returned future.
Co-authored-by: Wonwoo Choi <chwo9843@gmail.com>
177: implement DoubleEndedStream r=yoshuawuyts a=yoshuawuyts
Ref #129. This is the most basic version of the `DoubleEndedStream` trait. Because there is no counterpart in `futures-rs` we allow this to be implementable (not sure if we should though?).
This is not a high-priority trait to implement, with probably the most useful addition being the blanket impl over [`std::iter::Fuse`](https://doc.rust-lang.org/std/iter/struct.Fuse.html) (where we should have a `Fuse` counterpart for `Stream` also).
So I'm taking this one step at the time, and this PR introduces just the bare minimum to get things working. Thanks!
r? @stjepang @taiki-e
## Refs
- https://doc.rust-lang.org/std/iter/trait.DoubleEndedIterator.html
- #129
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
184: housekeeping after 145 r=yoshuawuyts a=montekki
Now that #145 is merged combinators can follow.
1. All combinators taking `&mut self` should imply `Self: Pin`.
2. Trait bounds are to `Stream`
3. Cleans up docs and `Debug` derives.
Co-authored-by: Fedor Sakharov <fedor.sakharov@gmail.com>
163: adds stream::filter_map combinator r=yoshuawuyts a=montekki
Implements a `flat_map` combinator. Currently the same about `ret!` as in #162 .
Also the naming should probably be `FilterMapStream`, but in that case `Take` stream should also change it's name i guess.
Stdlib: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.flat_map
Ref: #129
Co-authored-by: Fedor Sakharov <fedor.sakharov@gmail.com>
165: Fix a bug in conversion of File into raw handle r=stjepang a=stjepang
Same bugfix as #148, but applied to `async_std::fs::File`.
Co-authored-by: Stjepan Glavina <stjepang@gmail.com>
151: Split io into multiple files r=stjepang a=yoshuawuyts
Counterpart to #150, splits `io::read` and `io::write` into multiple files. This is useful to prevent a single file from becoming hard to navigate as we add more combinators. No other changes were made. Ref #131. Thanks!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
157: More robust file implementation r=stjepang a=stjepang
This is a reimplementation of the `File`s state machine.
The previous implementation was simple and a bit naive. It was not fundamentally wrong but had surprises in some corner cases. For example, if an async read operation was started but we timed out on it, the file cursor would move even though we didn't complete the operation. The new implementation will move the cursor only when read/write operations complete successfully.
There was also a deadlock hazard in the case where multiple tasks were concurrently reading or writing to the same file, in which case some task wakeups would be lost. This PR fixes the problem.
A nice consequence of this PR: `futures-channel` is now unused, so we can remove it from the dependency list.
Co-authored-by: Stjepan Glavina <stjepang@gmail.com>
Previously all of the into_raw_fd implementations only returns a copy of
the inner RawFd, while still holding the ownership of the file
descriptor when returning for into_raw_fd. Since `self` is dropped at
the end of into_raw_fd, the returned file descriptor will actually be
closed, render the function unuseable.
The patch makes sure that into_raw_fd actually takes the ownership of
the file descriptor all the way from the inner IoHandle. To achieve
this, I have to use an Option in IoHandle to store the I/O source. It's
not pretty, but I cannot come up with a better way.
* Add future::poll_fn
* Replace all uses of poll_fn with the new one
* Remove some uses of futures
* Simplify ReadDir and DirEntry
* Remove some use of futures from File
* Use futures subcrates
* Fix imports in docs
* Remove futures-util dependency
* Remove futures-executor-preview
* Refactor
* Require more features in the futures-preview crate
* Implement an async version of ToSocketAddrs
* fix documentation issue
* genius hack: pretending to be `impl Future`
* replace `std::net::ToSocketAddrs` with `async-std::net::ToSocketAddrs`
* Move unit tests into the tests directory
* Stylistic changes
* Remove re-exports in async_std::net
* fix broken link
* some mirror changes
* remove unnecessary format
* migrate: `std::net::ToSocketAddrs` -> `async_std::net::ToSocketAddrs`
* fix typo(tutorial)
* remove unnecessary type bound
* lifetime for future