OK, so I had a couple partially written replies on the 'deprecating
std.stream etc' thread, then I had to go home.
But I thought about this a lot last night, and some of the things Andrei
and others are saying is starting to make sense (I know!). Now I've
scrapped those replies and am thinking a
OK, so I had a couple partially written replies on the 'deprecating
std.stream etc' thread, then I had to go home.
But I thought about this a lot last night, and some of the things Andrei
and others are saying is starting to make sense (I know!). Now I've
scrapped those replies and am thinking a
On 5/17/12 9:02 AM, Steven Schveighoffer wrote:
1. We need a buffering input stream type. This must have additional
methods besides the range primitives, because doing one-at-a-time byte
reads is not going to cut it.
I was thinking a range of T[] could be enough for a buffered input range.
2.
On Thu, 17 May 2012 11:46:18 -0400, Andrei Alexandrescu
wrote:
On 5/17/12 9:02 AM, Steven Schveighoffer wrote:
Roughly speaking, not all the details are handled, but this makes a
feasible input range that will perform quite nicely for things like
std.algorithm.copy. I haven't checked, but co
I think range interface is not useful for *efficient* IO. The expected
IO interface will be more *abstract* than range primitives.
---
If you use range I/F to read bytes from device, we will always do
blocking IO - even if the device is socket. It is not efficient.
auto sock = new TcpSocketDevice
On Thursday, 17 May 2012 at 14:02:09 UTC, Steven Schveighoffer
wrote:
2. I realized, buffering input stream of type T is actually an
input range of type T[].
The trouble is, why a slice? Why not an std.array.Array? Why not
some other data source?
(Check/egg problem)
Another problem I'
On Friday, 18 May 2012 at 07:52:57 UTC, Mehrdad wrote:
On Thursday, 17 May 2012 at 14:02:09 UTC, Steven Schveighoffer
wrote:
2. I realized, buffering input stream of type T is actually an
input range of type T[].
The trouble is, why a slice? Why not an std.array.Array? Why
not some other data
On 05/18/12 06:19, kenji hara wrote:
> I think range interface is not useful for *efficient* IO. The expected
> IO interface will be more *abstract* than range primitives.
>
> ---
> If you use range I/F to read bytes from device, we will always do
> blocking IO - even if the device is socket. It i
On 18.05.2012 8:19, kenji hara wrote:
I think range interface is not useful for *efficient* IO. The expected
IO interface will be more *abstract* than range primitives.
---
If you use range I/F to read bytes from device, we will always do
blocking IO - even if the device is socket. It is not eff
On 05/18/12 13:34, Dmitry Olshansky wrote:
> On 18.05.2012 8:19, kenji hara wrote:
>> I think range interface is not useful for *efficient* IO. The expected
>> IO interface will be more *abstract* than range primitives.
>>
>> ---
>> If you use range I/F to read bytes from device, we will always do
On Fri, 18 May 2012 00:19:45 -0400, kenji hara wrote:
I think range interface is not useful for *efficient* IO. The expected
IO interface will be more *abstract* than range primitives.
If all you are doing is consuming data and processing it, range interface
is efficient. Most streaming im
On Fri, 18 May 2012 03:52:51 -0400, Mehrdad wrote:
On Thursday, 17 May 2012 at 14:02:09 UTC, Steven Schveighoffer wrote:
2. I realized, buffering input stream of type T is actually an input
range of type T[].
The trouble is, why a slice? Why not an std.array.Array? Why not some
other data
2012/5/18 Artur Skawina :
> On 05/18/12 06:19, kenji hara wrote:
>> I think range interface is not useful for *efficient* IO. The expected
>> IO interface will be more *abstract* than range primitives.
>>
>> ---
>> If you use range I/F to read bytes from device, we will always do
>> blocking IO - e
On Fri, 18 May 2012 07:05:50 -0400, Artur Skawina
wrote:
On 05/18/12 06:19, kenji hara wrote:
I think range interface is not useful for *efficient* IO. The expected
IO interface will be more *abstract* than range primitives.
---
If you use range I/F to read bytes from device, we will always
2012/5/18 Steven Schveighoffer :
> On Fri, 18 May 2012 00:19:45 -0400, kenji hara wrote:
>
>> I think range interface is not useful for *efficient* IO. The expected
>> IO interface will be more *abstract* than range primitives.
>
>
> If all you are doing is consuming data and processing it, range
On 05/18/12 15:51, kenji hara wrote:
> 2012/5/18 Artur Skawina :
>> On 05/18/12 06:19, kenji hara wrote:
>>> I think range interface is not useful for *efficient* IO. The expected
>>> IO interface will be more *abstract* than range primitives.
>>>
>>> ---
>>> If you use range I/F to read bytes from
On Fri, 18 May 2012 10:39:55 -0400, kenji hara wrote:
2012/5/18 Steven Schveighoffer :
On Fri, 18 May 2012 00:19:45 -0400, kenji hara
wrote:
I think range interface is not useful for *efficient* IO. The expected
IO interface will be more *abstract* than range primitives.
If all you are
On 5/18/12 2:52 AM, Mehrdad wrote:
On Thursday, 17 May 2012 at 14:02:09 UTC, Steven Schveighoffer wrote:
2. I realized, buffering input stream of type T is actually an input
range of type T[].
The trouble is, why a slice? Why not an std.array.Array? Why not some
other data source?
(Check/egg p
On Friday, 18 May 2012 at 13:44:43 UTC, Steven Schveighoffer
wrote:
On Fri, 18 May 2012 03:52:51 -0400, Mehrdad
wrote:
On Thursday, 17 May 2012 at 14:02:09 UTC, Steven Schveighoffer
wrote:
2. I realized, buffering input stream of type T is actually
an input range of type T[].
The trouble i
2012/5/19 Artur Skawina :
> On 05/18/12 15:51, kenji hara wrote:
>> OK. If reading bytes from underlying device failed, your 'fronts' can
>> return empty slice. I understood.
>> But, It is still *not efficient*. The returned slice will specifies a
>> buffer controlled by underlying device. If you w
On Fri, 18 May 2012 11:40:24 -0400, Mehrdad wrote:
On Friday, 18 May 2012 at 13:44:43 UTC, Steven Schveighoffer wrote:
On Fri, 18 May 2012 03:52:51 -0400, Mehrdad
wrote:
On Thursday, 17 May 2012 at 14:02:09 UTC, Steven Schveighoffer wrote:
2. I realized, buffering input stream of type T i
On Friday, 18 May 2012 at 15:49:23 UTC, Steven Schveighoffer
wrote:
I beg to differ..
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365469.aspx
It still reads into an array of buffers, which are slices. And
the resulting "range" looks *exactly* like a range of T[].
-Steve
Uh
On Fri, 18 May 2012 11:52:43 -0400, Mehrdad wrote:
On Friday, 18 May 2012 at 15:49:23 UTC, Steven Schveighoffer wrote:
I beg to differ..
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365469.aspx
It still reads into an array of buffers, which are slices. And the
resulting "ra
On Friday, 18 May 2012 at 15:57:20 UTC, Steven Schveighoffer
wrote:
So? So can a range of T[].
I'm not getting your point yet...
-Steve
Well you mentioned "There isn't an OS primitive that reads a file
descriptor into an e.g. linked list, anything other than a slice
would go through a tran
On Fri, 18 May 2012 12:02:16 -0400, Mehrdad wrote:
On Friday, 18 May 2012 at 15:57:20 UTC, Steven Schveighoffer wrote:
So? So can a range of T[].
I'm not getting your point yet...
-Steve
Well you mentioned "There isn't an OS primitive that reads a file
descriptor into an e.g. linked lis
On Friday, 18 May 2012 at 16:16:21 UTC, Steven Schveighoffer
wrote:
No, by range of T[] I mean this:
static assert(isInputRange!Range && is(ElementType!Range ==
T[]));
-Steve
Yes, I believe I understood it correctly...
In the case of ReadFileScatter, each T[] has the size of (at
most) 1 p
On 5/18/12 8:27 AM, Steven Schveighoffer wrote:
But be clear, I am *not* going to remove the existing stream I/O
primitives I had for buffered i/o, I'm rather *adding* range primitives
as well.
That sounds very promising.
Andrei
On 5/18/12 8:51 AM, kenji hara wrote:
OK. If reading bytes from underlying device failed, your 'fronts' can
return empty slice. I understood.
But, It is still *not efficient*. The returned slice will specifies a
buffer controlled by underlying device. If you want to gather bytes
into one chunk, y
On Friday, 18 May 2012 at 16:38:22 UTC, Andrei Alexandrescu wrote:
Range concept is good abstraction if underlying container
controlls
ownership. But, in I/O we want to *move* ownership of bytes.
Range is
not designed efficiently for the purpose, IMO.
Yes, yes, yes. Perfect thinking.
And I
2012/5/19 Steven Schveighoffer :
> On Fri, 18 May 2012 10:39:55 -0400, kenji hara wrote:
I'm designing experimental IO primitives:
https://github.com/9rnsr/dio
>
> I'm having trouble following the code, is there a place with the generated
> docs? I'm looking for an overview to understa
On 05/18/12 17:43, kenji hara wrote:
> 2012/5/19 Artur Skawina :
>> On 05/18/12 15:51, kenji hara wrote:
>>> OK. If reading bytes from underlying device failed, your 'fronts' can
>>> return empty slice. I understood.
>>> But, It is still *not efficient*. The returned slice will specifies a
>>> buff
2012/5/19 Steven Schveighoffer :
> On Fri, 18 May 2012 10:39:55 -0400, kenji hara wrote:
[snip]
>
> On non-blocking i/o, why not just not support range interface at all? I
> don't have any problem with that. In other words, if your input source is
> non-blocking, and you try to use range primiti
On Fri, 18 May 2012 13:27:22 -0400, kenji hara wrote:
2012/5/19 Steven Schveighoffer :
On Fri, 18 May 2012 10:39:55 -0400, kenji hara
wrote:
I'm designing experimental IO primitives:
https://github.com/9rnsr/dio
I'm having trouble following the code, is there a place with the
generated
On 05/18/12 20:18, Artur Skawina wrote:
> On 05/18/12 17:43, kenji hara wrote:
>> I'm designing experimental IO primitives:
>> https://github.com/9rnsr/dio
>
>> It has a sample benchmark to compare performance with std.stdio for
>> line iteration.
>
> It's not exactly what i had i mind, b
On 05/18/12 17:43, kenji hara wrote:
> I'm designing experimental IO primitives:
> https://github.com/9rnsr/dio
> It has a sample benchmark to compare performance with std.stdio for
> line iteration.
It's not exactly what i had i mind, but i tried to build it;
it wants a 'io/wrapper.d' mo
Sorry, I have updated it.
Run 'make runbench' or 'make runbench_opt'.
Kenji Hara
2012/5/19 Artur Skawina :
> On 05/18/12 17:43, kenji hara wrote:
>> I'm designing experimental IO primitives:
>> https://github.com/9rnsr/dio
>
>> It has a sample benchmark to compare performance with std.std
On Friday, 18 May 2012 at 19:18:21 UTC, Artur Skawina wrote:
On 05/18/12 20:18, Artur Skawina wrote:
On 05/18/12 17:43, kenji hara wrote:
I'm designing experimental IO primitives:
https://github.com/9rnsr/dio
It has a sample benchmark to compare performance with
std.stdio for
line iteration
Please add README to top directory.
(Contents are benchmark command, support environment and etc)
We can see such information on web browser ;)
P.S.
I want to do pull request for supporting other environments.
But I'm busy right now...
Masahiro
On Saturday, 19 May 2012 at 15:22:37 UTC, kenji
I don't have time to read the whole discussion right now, but I've
thought since our exchange here about buffered stream. I've imagined
something close to, but quite different from you buffered stream, where
the length of the buffer chunk can be adapted, and the buffer be poped
by an arbitrary
Well, because that's what i/o buffers are :) There isn't an OS
primitive that reads a file descriptor into an e.g. linked list.
Anything other than a slice would go through a translation.
It's a pity that iovec and T[] have switch length/ptr fields.
Otherwise one could directly map read(ub
40 matches
Mail list logo
