On Sunday, 7 February 2016 at 00:48:54 UTC, Jason White wrote:
> I'm interested in feedback on this library. What is it missing? How can be better?

I like what I've seen so far, but I'd just like to note that it's easier to give feedback on the API when there is web documentation. GitHub Pages would be a natural place to host it.

A lot of D libraries on GitHub do this and not everyone uses the same tools, but for one example, here's LuaD[1] with reference documentation on GitHub pages, automatically generated and pushed by Travis-CI for the master branch.

https://github.com/JakobOvrum/LuaD

I think this is a huge task and requires a (huge) DIP, and collaborative effort of coming up with a good, really good, API for BOTH synchronous and asynchronous IO. As mentioned in the previous messages, there is already an asyncio library, although I am not sure it is good enough to be in Phobos...

I know people may not like Boost, but Boost.Asio is amazing and we should perhaps use it as a guide, if not copy the whole API...

On Monday, 8 February 2016 at 09:08:53 UTC, Dejan Lekic wrote:
> I think this is a huge task and requires a (huge) DIP, and collaborative effort of coming up with a good, really good, API for BOTH synchronous and asynchronous IO. As mentioned in the previous messages, there is already an asyncio library, although I am not sure it is good enough to be in Phobos...

I don't think we've used DIPs for library additions before. I don't see what it would provide over module documentation.

On Monday, 8 February 2016 at 09:12:25 UTC, Jakob Ovrum wrote:
> I don't think we've used DIPs for library additions before. I don't see what it would provide over module documentation.

Probably because a standard library should keep things simple, meaning it should unify high level  functionality on aggregates as ranges/iterators or a generalization over streams/ranges that is as simple as possible across the board.

If not, then why have it in the standard library?

On Sunday, 7 February 2016 at 00:48:54 UTC, Jason White wrote:
>     GitHub:  https://github.com/jasonwhite/io

In the output stream you compare output data length to the input data length. In case of a transcoding stream they can be different. Are you trying to account for partial writes?

On Monday, 8 February 2016 at 09:08:53 UTC, Dejan Lekic wrote:
> I think this is a huge task and requires a (huge) DIP, and collaborative effort of coming up with a good, really good, API for BOTH synchronous and asynchronous IO. As mentioned in the previous messages, there is already an asyncio library, although I am not sure it is good enough to be in Phobos...
>
> I know people may not like Boost, but Boost.Asio is amazing and we should perhaps use it as a guide, if not copy the whole API...

I like boost. Well, sometimes. I _severely_ dislike boost::asio. The new couroutines may make it easier to use, I'd have to try 1st, but what's the point when vibe.d exists?

Atila

On Sunday, 7 February 2016 at 00:48:54 UTC, Jason White wrote:
>
> This library provides an input and output range interface for streams (which is more efficient if the stream is buffered). Thus, many of the wonderful range operations from std.range and std.algorithm can be used with this.
>
Ah, grand!  I love the idea and my impression from browsing the source a bit is positive enough to say I'm looking forward to what comes out of this.

Though I AM a little ambivalent-- I had a series of pretty in-depth conversations on this topic with a friend a while back and we came to a consensus that stream semantics are a tricky thing because of the historical baggage around them and how they tend to get conflated with other concepts.

Looking at your API design, I think you've hit close to a lot of the same conclusions we reached, but here are the notes I took for the sake of providing an additional perspective:
http://radiusic.com/doc/streamNotes (Sorry, I tried just pasting them and it was moderately unreadable even in the preview)

I think the most important things we hit upon are:
1. A stream is fundamentally unidirectional.
2. A stream is raw, untyped data that becomes a range through an adapter that mediates access.

-Wyatt

On Mon, 08 Feb 2016 12:19:59 +0000, Atila Neves wrote:

> On Monday, 8 February 2016 at 09:08:53 UTC, Dejan Lekic wrote:
>> I think this is a huge task and requires a (huge) DIP, and collaborative effort of coming up with a good, really good, API for BOTH synchronous and asynchronous IO. As mentioned in the previous messages, there is already an asyncio library, although I am not sure it is good enough to be in Phobos...
>>
>> I know people may not like Boost, but Boost.Asio is amazing and we should perhaps use it as a guide, if not copy the whole API...
> 
> I like boost. Well, sometimes. I _severely_ dislike boost::asio.
> The new couroutines may make it easier to use, I'd have to try 1st, but
> what's the point when vibe.d exists?
> 
> Atila

I can't use vibe.d for one of my projects because I need to keep tight control of coroutine scheduling. Better async IO routines in Phobos would help me -- though I'm mainly looking for higher level stuff, like a telnet handler.

On Monday, 8 February 2016 at 17:11:56 UTC, Chris Wright wrote:
> On Mon, 08 Feb 2016 12:19:59 +0000, Atila Neves wrote:
>
>> On Monday, 8 February 2016 at 09:08:53 UTC, Dejan Lekic wrote:
>>> [...]
>> 
>> I like boost. Well, sometimes. I _severely_ dislike boost::asio.
>> The new couroutines may make it easier to use, I'd have to try 1st, but
>> what's the point when vibe.d exists?
>> 
>> Atila
>
> I can't use vibe.d for one of my projects because I need to keep tight control of coroutine scheduling. Better async IO routines in Phobos would help me -- though I'm mainly looking for higher level stuff, like a telnet handler.

You can always use fibers yourself and just do the IO there. It's cooperative multithreading so you control when one of them yields.

Atila

On Monday, 8 February 2016 at 07:50:33 UTC, Jakob Ovrum wrote:
> I like what I've seen so far, but I'd just like to note that it's easier to give feedback on the API when there is web documentation. GitHub Pages would be a natural place to host it.
>
> A lot of D libraries on GitHub do this and not everyone uses the same tools, but for one example, here's LuaD[1] with reference documentation on GitHub pages, automatically generated and pushed by Travis-CI for the master branch.
>
> https://github.com/JakobOvrum/LuaD

Done: https://jasonwhite.github.io/io/

(Nice work on bootDoc!)

I haven't tied it in with the Travis build yet, but that shouldn't be too hard to do.

Pretty docs typically helps motivate me to write more.