On Wednesday, 27 July 2016 at 06:18:07 UTC, Sönke Ludwig wrote:
Am 26.07.2016 um 16:50 schrieb Johannes Pfau:
Am Mon, 25 Jul 2016 13:10:42 +
Hello,
I don't know if it is good practice or not, but sometimes it
make
life easier if you can put part of the data back into the
input
stream.
Am 26.07.2016 um 16:50 schrieb Johannes Pfau:
Am Mon, 25 Jul 2016 13:10:42 +
Hello,
I don't know if it is good practice or not, but sometimes it make
life easier if you can put part of the data back into the input
stream.
Writing data back to a stream is quite uncommon. The standard
Am Sun, 24 Jul 2016 13:03:01 +
schrieb Martin Nowak :
> 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 think making the actual read/write/open/accept/et.al.
Am Mon, 25 Jul 2016 13:10:42 +
schrieb ikod :
> On Sunday, 7 February 2016 at 00:48:54 UTC, Jason White wrote:
> > I see the subject of IO streams brought up here occasionally.
> > The general consensus seems to be that we need something better
> > than what Phobos
On Sunday, 7 February 2016 at 00:48:54 UTC, Jason White wrote:
I see the subject of IO streams brought up here occasionally.
The general consensus seems to be that we need something better
than what Phobos provides.
I wrote a library "io" that can work as a replacement for
std.stdio,
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 think making the actual read/write/open/accept/et.al. functions
used to talk to the kernel pluggable would be a good extension
point to hook in
On Sunday, 7 February 2016 at 00:48:54 UTC, Jason White wrote:
I'm also interested in a discussion of what IO-related
functionality people are missing in Phobos.
This is still a very interesting approach that could even become
a candidate for std.io at some point. Would be great if we could
On Monday, 8 February 2016 at 20:21:31 UTC, Jason White wrote:
Reads and writes are not guaranteed to fill/write the entire
buffer you throw at it. This is what readExactly/writeExactly
are for. Those will throw an exception if the entire read/write
cannot be done.
You mean posix
On Tue, 09 Feb 2016 09:45:03 +, Kagamin wrote:
> On Monday, 8 February 2016 at 20:21:31 UTC, Jason White wrote:
>> Reads and writes are not guaranteed to fill/write the entire buffer you
>> throw at it. This is what readExactly/writeExactly are for. Those will
>> throw an exception if the
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,
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
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
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
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
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 17:11:56 UTC, Chris Wright wrote:
On Mon, 08 Feb 2016 12:19:59 +, 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
On Mon, 08 Feb 2016 12:19:59 +, 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
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
On Monday, 8 February 2016 at 12:02:08 UTC, Kagamin wrote:
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?
Reads and writes are not guaranteed to fill/write the
On Mon, 08 Feb 2016 18:52:52 +, Atila Neves wrote:
> On Monday, 8 February 2016 at 17:11:56 UTC, Chris Wright wrote:
>> On Mon, 08 Feb 2016 12:19:59 +, Atila Neves wrote:
>>
>>> On Monday, 8 February 2016 at 09:08:53 UTC, Dejan Lekic wrote:
[...]
>>>
>>> I like boost. Well,
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
Am Sun, 07 Feb 2016 00:48:54 +
schrieb Jason White <54f9byee3...@gmail.com>:
> I see the subject of IO streams brought up here occasionally. The
> general consensus seems to be that we need something better than
> what Phobos provides.
>
> I wrote a library "io" that can work as a
On Sunday, 7 February 2016 at 10:50:24 UTC, Johannes Pfau wrote:
I saw this on code.dlang.org some time ago and had a quick
look. First of all this would have to go into phobos to make
sure it's used as some kind of a standard. Conflicting stream
libraries would only cause more trouble.
Then
On Sunday, 7 February 2016 at 00:48:54 UTC, Jason White wrote:
I see the subject of IO streams brought up here occasionally.
The general consensus seems to be that we need something better
than what Phobos provides.
[...]
From what I can see without testing it, very nice work, thanks!
More
On Sunday, 7 February 2016 at 01:59:43 UTC, Rikki Cattermole
wrote:
Actually I think there are plenty of use cases not implemented.
Done properly as a full replacement and rework of Phobos will
mean you need to do almost everything in e.g. std.stdio and
std.socket but with better abstractions.
On 07/02/16 3:43 PM, Jason White wrote:
On Sunday, 7 February 2016 at 01:59:43 UTC, Rikki Cattermole wrote:
Actually I think there are plenty of use cases not implemented.
Done properly as a full replacement and rework of Phobos will mean you
need to do almost everything in e.g. std.stdio and
On 07/02/16 1:48 PM, Jason White wrote:
I see the subject of IO streams brought up here occasionally. The
general consensus seems to be that we need something better than what
Phobos provides.
I wrote a library "io" that can work as a replacement for std.stdio,
std.mmfile, std.cstream, and
On Sunday, 7 February 2016 at 01:01:21 UTC, cym13 wrote:
From what I can see without testing it, very nice work, thanks!
More a little surprise than anything serious though, why did
you choose to go with "println" instead of "writeln" and such?
I find it more confusing than anything given
On Sunday, 7 February 2016 at 01:20:26 UTC, Rikki Cattermole
wrote:
I posted a link to your repo a couple days ago in IRC.
Honestly? I like it. It looks reasonably well made.
Thanks. I saw a link to it in a recent thread in Learn. I figured
I'd finally make a proper post on it.
There is a
On 07/02/16 2:55 PM, Jason White wrote:
On Sunday, 7 February 2016 at 01:20:26 UTC, Rikki Cattermole wrote:
I posted a link to your repo a couple days ago in IRC.
Honestly? I like it. It looks reasonably well made.
Thanks. I saw a link to it in a recent thread in Learn. I figured I'd
finally
30 matches
Mail list logo