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
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. The
Andrei Alexandrescu Wrote:
With these primitives a lot of good operating operating on buffered
streams can be written efficiently. The range is allowed to reuse data
in its buffers (unless that would contradict language invariants, e.g.
if T is invariant), so if client code wants to stash
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 of this on
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 of this
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 Saturday 05 February 2011 12:57:21 Jonathan M Davis wrote:
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
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
On Friday 04 February 2011 21:46:40 Andrei Alexandrescu 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 commonalities and some
differences, but it's
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, then
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 is that, if
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
Dang, you beat me to my post on what I have run into trying to provide a
slice-able, assignable, buffered Forward Range.
I was doing some work on a CSV parser. It is rather simple to build a proper
parser from an input range. But providing the ability to use custom separators
which could be of
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 it to be
Nice!
And evenin'!
Layman's view:
- - - - - - - - - - -
(I'm serious, please don't take my post too seriously. I'm not a heavy user of
D and I don't want to pollute. I know in NGs exposure means influence and I
babble a lot. Still, my thoughts, or rather reactions, could be of interest, I
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 a
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 is that, if
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
On 02/05/2011 06:42 PM, Heywood Floyd wrote:
Nice!
And evenin'!
Layman's view:
- - - - - - - - - - -
(I'm serious, please don't take my post too seriously. I'm not a heavy user of
D and I don't want to pollute. I know in NGs exposure means influence and I
babble a lot. Still, my thoughts,
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
Interesting. I was just writing LazyMap and AsyncBuf in
std.parallelism, and I ran into these exact issues. (A LazyMap computes
a map lazily and in parallel and stores the result in a buffer. An
AsyncBuf reads from an unbuffered input range in a background thread and
buffers the results for
On 02/04/2011 11:46 PM, Andrei Alexandrescu 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 commonalities and some
differences, but it's been
On 2011-02-05 00:46:40 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
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 commonalities and
78 matches
Mail list logo
