On Sat, 05 Feb 2011 00:46:40 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I've had the opportunity today to put some solid hours of thinking into
the relationship (better said the relatedness) of what would be called
buffered streams and ranges. They have some
On Sun, 06 Feb 2011 10:25:15 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
How does the stream decide between 1 and 2? Clearly it's undesirable to
grow the buffer too much and it's also undesirable to copy too much
data. A simple approach is to establish a bound on
On Sat, 05 Feb 2011 10:02:47 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/5/11 2:45 AM, Michel Fortin wrote:
One thing I'm wondering is whether it'd be more efficient if we could
provide our own buffer to be filled. In cases where you want to preserve
the data, this
a structure for depositing the output.
---
Let's restart this. What do you want to do that you can't do with the proposed
API?
First, I would love to read about some typical or sample uses of buffered input
(hopefully clearly explained); especially showing why how buffering is a true
On 02/07/2011 02:01 PM, Steven Schveighoffer wrote:
On Sat, 05 Feb 2011 10:02:47 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/5/11 2:45 AM, Michel Fortin wrote:
One thing I'm wondering is whether it'd be more efficient if we could
provide our own buffer to be filled.
On 2011-02-07 08:24:32 -0500, spir denis.s...@gmail.com said:
Does this have anything to do with currently discussed buffered input
ranges? If yes, how does such a design, or any alternative, fit their
proposed interface?
You can build all of this on top of a buffered input range
away parts of the
input, it needs to make a copy.
This surely satisfies most needs for buffered input.
I'm thinking about adaptive caller which can do tricks based on the stream
content. Say, strings are usually serialized as |length|data| so the caller can
preallocate buffer of exact length
On 2/7/11 7:53 AM, Steven Schveighoffer wrote:
On Sat, 05 Feb 2011 00:46:40 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I've had the opportunity today to put some solid hours of thinking
into the relationship (better said the relatedness) of what would be
called buffered
On 2/7/11 9:40 AM, Michel Fortin wrote:
On 2011-02-07 08:24:32 -0500, spir denis.s...@gmail.com said:
Does this have anything to do with currently discussed buffered input
ranges? If yes, how does such a design, or any alternative, fit their
proposed interface?
You can build all
On 02/07/2011 03:40 PM, Michel Fortin wrote:
On 2011-02-07 08:24:32 -0500, spir denis.s...@gmail.com said:
Does this have anything to do with currently discussed buffered input ranges?
If yes, how does such a design, or any alternative, fit their proposed
interface?
You can build all
On 2011-02-07 13:25:53 -0500, spir denis.s...@gmail.com said:
On 02/07/2011 03:40 PM, Michel Fortin wrote:
On 2011-02-07 08:24:32 -0500, spir denis.s...@gmail.com said:
Does this have anything to do with currently discussed buffered input ranges?
If yes, how does such a design, or any
on buffered input is that I
don't want to worry about it. I want it to be buffered so that it's
more efficient, but I don't want to have to care about it in how I use
it. I would have expected a buffered input range to be exactly the
same as an input range except that it doesn't really just pull
On 02/06/2011 04:11 AM, Andrei Alexandrescu wrote:
On 2/5/11 5:22 PM, Nick Sabalausky wrote:
Heywood Floydsoul...@gmail.com wrote in message
news:mailman.1318.1296941395.4748.digitalmar...@puremagic.com...
As in, you've built some library that passes around ranges, but then some
part of it is
Nick Sabalausky napisał:
discard and fetch?
I like that.
On 2011-02-06 03:22:08 -0500, Jonathan M Davis jmdavisp...@gmx.com said:
So, maybe I'm still misunderstanding or missing something here, but what _I_
want to see for I/O streams is a _forward_ range which is buffered and which
reads in the file or whatever the data comes from in a lazy manner.
On 2/6/11 3:22 EST, Jonathan M Davis wrote:
Okay. I think that I've been misunderstanding some stuff here. I forgot that we
were dealing with input ranges rather than forward ranges, and many range
functions just don't work with input ranges, since they lack save(). Bleh.
Okay. Honestly, what
On 2/6/11 0:01 EST, Nick Sabalausky wrote:
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message
news:iil64l$1f6s$1...@digitalmars.com...
On 2/5/11 7:28 PM, Don wrote:
Circular buffers don't seem like an 'optional' use case to me. Most real
I/O works that way.
I think if the
On 2/6/11 6:01 EST, Tomek Sowiński wrote:
Nick Sabalausky napisał:
discard and fetch?
I like that.
What's missing is the part that they refer to front. Maybe
discardFromFront() and fetchToFront()? But then I like
discardFromFront() and appendToFront() better - the latter is about as
On 02/06/2011 04:25 PM, Andrei Alexandrescu wrote:
Say the buffer has 1000 elements of which the last 100 contain data (and the
other 900 are past data that's not used). Then say this request comes:
stream.appendToFront(150);
At this point the stream may go two ways:
1. Append to the internal
On 2/6/11 12:42 PM, spir wrote:
On 02/06/2011 04:25 PM, Andrei Alexandrescu wrote:
Say the buffer has 1000 elements of which the last 100 contain data
(and the
other 900 are past data that's not used). Then say this request comes:
stream.appendToFront(150);
At this point the stream may go two
Andrei Alexandrescu napisał:
Also: could a (truely) circular buffer help solve the above copy
problem, concretely?
Not if you want infinite lookahead, which I think is what any modern
buffering system should offer.
Truely circular, probably not, but a wrap-around slice (circular view
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:iimnm6$1m4a$2...@digitalmars.com...
On 2/6/11 12:42 PM, spir wrote:
Also: could a (truely) circular buffer help solve the above copy
problem, concretely?
Not if you want infinite lookahead, which I think is what any
On 02/06/2011 08:49 PM, Tomek Sowiński wrote:
Andrei Alexandrescu napisał:
Also: could a (truely) circular buffer help solve the above copy
problem, concretely?
Not if you want infinite lookahead, which I think is what any modern
buffering system should offer.
Truely circular, probably
On 2/6/11 4:13 PM, Nick Sabalausky wrote:
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message
news:iimnm6$1m4a$2...@digitalmars.com...
On 2/6/11 12:42 PM, spir wrote:
Also: could a (truely) circular buffer help solve the above copy
problem, concretely?
Not if you want
On 2/6/11 4:51 PM, spir wrote:
On 02/06/2011 08:49 PM, Tomek Sowiński wrote:
Andrei Alexandrescu napisał:
Also: could a (truely) circular buffer help solve the above copy
problem, concretely?
Not if you want infinite lookahead, which I think is what any modern
buffering system should offer.
On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/6/11 6:01 EST, Tomek Sowiński wrote:
Nick Sabalausky napisał:
discard and fetch?
I like that.
What's missing is the part that they refer to front. Maybe
discardFromFront() and
2011/2/7 Robert Jacques sandf...@jhu.edu:
On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/6/11 6:01 EST, Tomek Sowiński wrote:
Nick Sabalausky napisał:
discard and fetch?
I like that.
What's missing is the part that they refer to front.
On 2/6/11 8:57 PM, Robert Jacques wrote:
On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/6/11 6:01 EST, Tomek Sowiński wrote:
Nick Sabalausky napisał:
discard and fetch?
I like that.
What's missing is the part that they refer to front.
2011/2/7 Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 2/6/11 9:47 PM, Torarin wrote:
2011/2/7 Robert Jacquessandf...@jhu.edu:
On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/6/11 6:01 EST, Tomek Sowiński wrote:
Nick Sabalausky
On Sun, 06 Feb 2011 21:53:01 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/6/11 8:57 PM, Robert Jacques wrote:
On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/6/11 6:01 EST, Tomek Sowiński wrote:
Nick Sabalausky
On 2/6/11 10:37 PM, Robert Jacques wrote:
On Sun, 06 Feb 2011 21:53:01 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/6/11 8:57 PM, Robert Jacques wrote:
On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/6/11 6:01 EST,
On Sun, 06 Feb 2011 21:47:48 -0500, Torarin torar...@gmail.com wrote:
2011/2/7 Robert Jacques sandf...@jhu.edu:
On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/6/11 6:01 EST, Tomek Sowiński wrote:
Nick Sabalausky napisał:
discard and
On 2/6/11 10:59 PM, Robert Jacques wrote:
On Sun, 06 Feb 2011 21:47:48 -0500, Torarin torar...@gmail.com wrote:
2011/2/7 Robert Jacques sandf...@jhu.edu:
On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/6/11 6:01 EST, Tomek Sowiński wrote:
2011/2/7 Robert Jacques sandf...@jhu.edu:
On Sun, 06 Feb 2011 21:47:48 -0500, Torarin torar...@gmail.com wrote:
2011/2/7 Robert Jacques sandf...@jhu.edu:
On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/6/11 6:01 EST, Tomek Sowiński wrote:
On Sun, 06 Feb 2011 23:01:12 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/6/11 10:59 PM, Robert Jacques wrote:
On Sun, 06 Feb 2011 21:47:48 -0500, Torarin torar...@gmail.com wrote:
2011/2/7 Robert Jacques sandf...@jhu.edu:
On Sun, 06 Feb 2011 10:43:47 -0500, Andrei
.
At this point we need to ask ourselves an essential question. Since we
have this input range abstraction for a 1-element buffer, what would
its n-elements buffer representation look like? How do we go from input
range of T (which really is unbuffered input range of T to buffered
input range of T
On 02/05/2011 10:36 AM, Nick Sabalausky wrote:
On a separate note, I think a good way of testing the design (and end up
getting something useful anyway) would be to try to use it to create a range
that's automatically-buffered in a more traditional way. Ie, Given any input
range 'myRange',
On 02/05/2011 08:22 AM, Ellery Newcomer wrote:
2. R defines a primitive shiftFront(size_t n). The semantics of the
primitive is that, if r.front.length = n, then shiftFront(n) discards
the first n elements in r.front. Subsequently r.front will return a
slice of the remaining elements.
Does
Andrei:
I've had the opportunity today to put some solid hours of thinking into
the relationship (better said the relatedness) of what would be called
buffered streams and ranges.
This is an important part of the range design. This range is useful for other
things too, like:
- increasing
On 02/05/2011 11:09 AM, Jonathan M Davis wrote:
Hmm. I think that I'd have to have an actual implementation to mess around with
to say much. My general take on buffered input is that I don't want to worry
about it. I want it to be buffered so that it's more efficient, but I don't
want to
have
On 02/05/2011 08:45 AM, Michel Fortin wrote:
One thing I'm wondering is whether it'd be more efficient if we could provide
our own buffer to be filled. In cases where you want to preserve the data, this
could let you avoid double-copying: first copy in the temporary buffer and then
at the
Does shiftFront literally move element n to index 0 and so on? It seems
to me that if you do, its going to have horrid performance, and if you
don't, then you will eventually run into situations where appendToFront
will require a wrap around, which loses you your contiguity, or a
Andrei Alexandrescu napisał:
I hereby suggest we define buffered input range of T any range R that
satisfies the following conditions:
1. R is an input range of T[]
2. R defines a primitive shiftFront(size_t n). The semantics of the
primitive is that, if r.front.length = n
Tomek Sowiński napisał:
Contiguous, yes. But I'd rather see front() exposing, say, a circular buffer
so that appendToFront(n)
reallocates only when n buf.length.
I meant: when n + front.length buf.length.
--
Tomek
Tomek Sowiñski Wrote:
Andrei Alexandrescu napisa³:
I hereby suggest we define buffered input range of T any range R that
satisfies the following conditions:
1. R is an input range of T[]
2. R defines a primitive shiftFront(size_t n). The semantics of the
primitive
On 2011-02-05 07:01:24 -0500, spir denis.s...@gmail.com said:
On 02/05/2011 08:45 AM, Michel Fortin wrote:
One thing I'm wondering is whether it'd be more efficient if we could provide
our own buffer to be filled. In cases where you want to preserve the data, this
could let you avoid
On 2/5/11 2:22 AM, Ellery Newcomer wrote:
Does shiftFront literally move element n to index 0 and so on? It seems
to me that if you do, its going to have horrid performance, and if you
don't, then you will eventually run into situations where appendToFront
will require a wrap around, which loses
On 2/5/11 2:45 AM, Michel Fortin wrote:
One thing I'm wondering is whether it'd be more efficient if we could
provide our own buffer to be filled. In cases where you want to preserve
the data, this could let you avoid double-copying: first copy in the
temporary buffer and then at the permanent
On 2011-02-05 10:02:47 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
Generally when one says I want the stream to copy data straight into
my buffers this is the same as I want the stream to be unbuffered.
So if you want to provide your own buffers to be filled, we need to
Andrei Alexandrescu napisał:
Transparent buffering sounds sensible but in fact it robs you of
important capabilities. It essentially forces you to use grammars with
lookahead 1 for all input operations. Being able to peek forward into
the stream without committing to read from it allows
Andrei Alexandrescu napisał:
I don't see a clear need for the two to be separate. Could they fold
into popFront(n, m) meaning shiftFront(n); appendToFront(m) ? Nullary
popFront() discards all and loads any number it pleases.
I think combining the two into one hurts usability as often
Jean Crystof napisał:
I find this discussion interesting. There's one idea for an application I'd
like to try at some point. Basically a facebook chat thingie, but with richer
gaming features. The expected audience will be 10 - 100K simultaneous clients
connecting to a single server. Not
, World;
auto len = countUntil(range, ,);
assert(range[0..len] == Hello);
where range is replaced by a buffered Input Range. And as an added bonus:
range = range[len..$];
assert(range == ,World);
You can of course use the Range for equality, instead of strings like Hello.
1.
https
On Saturday 05 February 2011 07:16:45 Andrei Alexandrescu wrote:
On 2/5/11 5:09 AM, Jonathan M Davis wrote:
Hmm. I think that I'd have to have an actual implementation to mess
around with to say much. My general take on buffered input is that I
don't want to worry about it. I want
assume, or I wouldn't be writing this : )
I'm not sure how these buffered input ranges are supposed to be used (some
mockup sample code would be very cool!), but it seems to me, and please correct
me if I'm wrong, that it's very desirable for these ranges to be
interchangeable?
As in, you've
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:iijq99$1a5o$1...@digitalmars.com...
On 2/5/11 6:46 AM, spir wrote:
On 02/05/2011 10:36 AM, Nick Sabalausky wrote:
On a separate note, I think a good way of testing the design (and end up
getting something useful anyway)
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:iijpp7$197f$1...@digitalmars.com...
On 2/5/11 5:09 AM, Jonathan M Davis wrote:
Hmm. I think that I'd have to have an actual implementation to mess
around with
to say much. My general take on buffered input is that I
Jean Crystof a@a.a wrote in message
news:iijl2t$10np$1...@digitalmars.com...
Tomek Sowiñski Wrote:
Andrei Alexandrescu napisa³:
I hereby suggest we define buffered input range of T any range R that
satisfies the following conditions:
1. R is an input range of T[]
2. R defines
Heywood Floyd soul...@gmail.com wrote in message
news:mailman.1318.1296941395.4748.digitalmar...@puremagic.com...
As in, you've built some library that passes around ranges, but then some
part of it is slow and needs buffered ones. Isn't the point that you can
then swap out your ranges for
2011/2/5 Andrei Alexandrescu seewebsiteforem...@erdani.org:
I hereby suggest we define buffered input range of T any range R that
satisfies the following conditions:
1. R is an input range of T[]
2. R defines a primitive shiftFront(size_t n). The semantics of the
primitive
On 02/05/2011 10:44 PM, Nick Sabalausky wrote:
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message
news:iijq99$1a5o$1...@digitalmars.com...
On 2/5/11 6:46 AM, spir wrote:
On 02/05/2011 10:36 AM, Nick Sabalausky wrote:
On a separate note, I think a good way of testing the design
On 02/05/2011 11:00 PM, Nick Sabalausky wrote:
Transparent buffering sounds sensible but in fact it robs you of important
capabilities. It essentially forces you to use grammars with lookahead 1
for all input operations. Being able to peek forward into the stream
without committing to read
On 2/5/11 12:59 PM, Tomek Sowiński wrote:
Andrei Alexandrescu napisał:
Transparent buffering sounds sensible but in fact it robs you of
important capabilities. It essentially forces you to use grammars with
lookahead 1 for all input operations. Being able to peek forward into
the stream
spir wrote:
On 02/05/2011 10:44 PM, Nick Sabalausky wrote:
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message
news:iijq99$1a5o$1...@digitalmars.com...
On 2/5/11 6:46 AM, spir wrote:
On 02/05/2011 10:36 AM, Nick Sabalausky wrote:
On a separate note, I think a good way of
On 2/5/11 1:18 PM, Tomek Sowiński wrote:
Andrei Alexandrescu napisał:
I don't see a clear need for the two to be separate. Could they fold
into popFront(n, m) meaning shiftFront(n); appendToFront(m) ? Nullary
popFront() discards all and loads any number it pleases.
I think combining the two
On 02/05/2011 11:22 PM, Nick Sabalausky wrote:
Heywood Floydsoul...@gmail.com wrote in message
news:mailman.1318.1296941395.4748.digitalmar...@puremagic.com...
As in, you've built some library that passes around ranges, but then some
part of it is slow and needs buffered ones. Isn't the point
On Sat, 05 Feb 2011 17:22:01 -0500, Nick Sabalausky a@a.a wrote:
Heywood Floyd soul...@gmail.com wrote in message
news:mailman.1318.1296941395.4748.digitalmar...@puremagic.com...
As in, you've built some library that passes around ranges, but then
some
part of it is slow and needs buffered
, or rather reactions, could be of interest, I
assume, or I wouldn't be writing this : )
I'm not sure how these buffered input ranges are supposed to be used (some
mockup sample code would be very cool!), but it seems to me, and please correct
me if I'm wrong, that it's very desirable
On 02/06/2011 01:28 AM, Don wrote:
spir wrote:
On 02/05/2011 10:44 PM, Nick Sabalausky wrote:
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message
news:iijq99$1a5o$1...@digitalmars.com...
On 2/5/11 6:46 AM, spir wrote:
On 02/05/2011 10:36 AM, Nick Sabalausky wrote:
On a
Andrei Alexandrescu napisał:
I fear efficiency will get abstracted out. Say this is my internal buffer
(pipes indicate front() slice):
[ooo|oo|oo]
Now I do appendToFront(3) -- how do you expose the expected front() without
moving data?
You do end up moving data, but
spir denis.s...@gmail.com wrote in message
news:mailman.1321.1296950957.4748.digitalmar...@puremagic.com...
On 02/05/2011 11:00 PM, Nick Sabalausky wrote:
Transparent buffering sounds sensible but in fact it robs you of
important
capabilities. It essentially forces you to use grammars with
On 2/5/11 5:22 PM, Nick Sabalausky wrote:
Heywood Floydsoul...@gmail.com wrote in message
news:mailman.1318.1296941395.4748.digitalmar...@puremagic.com...
As in, you've built some library that passes around ranges, but then some
part of it is slow and needs buffered ones. Isn't the point that
This sounds similar to how my network code works. I called
the functions fetchMore() to append to the buffer and eat(int n)
to advance the front position.
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:iil3lv$1bb1$1...@digitalmars.com...
On 2/5/11 5:22 PM, Nick Sabalausky wrote:
Heywood Floydsoul...@gmail.com wrote in message
news:mailman.1318.1296941395.4748.digitalmar...@puremagic.com...
As in, you've built some
On 2/5/11 7:28 PM, Don wrote:
spir wrote:
On 02/05/2011 10:44 PM, Nick Sabalausky wrote:
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message
news:iijq99$1a5o$1...@digitalmars.com...
On 2/5/11 6:46 AM, spir wrote:
On 02/05/2011 10:36 AM, Nick Sabalausky wrote:
On a separate
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:iil64l$1f6s$1...@digitalmars.com...
On 2/5/11 7:28 PM, Don wrote:
Circular buffers don't seem like an 'optional' use case to me. Most real
I/O works that way.
I think if the abstraction can't handle it, the abstraction
we
have this input range abstraction for a 1-element buffer, what would
its n-elements buffer representation look like? How do we go from input
range of T (which really is unbuffered input range of T to buffered
input range of T?
Honestly, the answer was extremely unclear to me for the longest
an essential question. Since we
have this input range abstraction for a 1-element buffer, what would
its n-elements buffer representation look like? How do we go from input
range of T (which really is unbuffered input range of T to buffered
input range of T?
Honestly, the answer was extremely unclear to me
ourselves an essential question. Since we
have this input range abstraction for a 1-element buffer, what would
its n-elements buffer representation look like? How do we go from input
range of T (which really is unbuffered input range of T to buffered
input range of T?
Honestly, the answer was extremely
to
buffered input range of T?
Honestly, the answer was extremely unclear to me for the longest time.
I thought that such a range would be an extension of the unbuffered
one, e.g. a range that still offers T from front() but also offers some
additional functions - e.g. a lookahead in the form
80 matches
Mail list logo
