On 4/30/20 6:39 PM, Paul Backus wrote:
On Thursday, 30 April 2020 at 18:30:14 UTC, H. S. Teoh wrote:
Also, for ranges based on generator functions, if .front is lazy then
you need to keep extra baggage around your range to indicate whether
or not the generator has been invoked yet; it's easier
On Thursday, 30 April 2020 at 18:30:14 UTC, H. S. Teoh wrote:
On Thu, Apr 30, 2020 at 06:05:55PM +, Paul Backus via
Digitalmars-d-learn wrote: [...]
Doing work in popFront instead of front is usually an
anti-pattern, since it forces eager evaluation of the next
element even when that
On 4/30/20 2:30 PM, H. S. Teoh wrote:
On Thu, Apr 30, 2020 at 06:05:55PM +, Paul Backus via Digitalmars-d-learn
wrote:
[...]
Doing work in popFront instead of front is usually an anti-pattern,
since it forces eager evaluation of the next element even when that
element is never used. You
On 4/30/20 2:05 PM, Paul Backus wrote:
On Thursday, 30 April 2020 at 16:21:05 UTC, Steven Schveighoffer wrote:
I would say part of the issue is that you are doing all your work in
front and not popFront.
[...]
I'd say:
1. move your work to the popFront function (you then need to call
On Thursday, 30 April 2020 at 18:30:14 UTC, H. S. Teoh wrote:
On Thu, Apr 30, 2020 at 06:05:55PM +, Paul Backus via
Digitalmars-d-learn wrote: [...]
Doing work in popFront instead of front is usually an
anti-pattern, since it forces eager evaluation of the next
element even when that
On Thu, Apr 30, 2020 at 06:05:55PM +, Paul Backus via Digitalmars-d-learn
wrote:
[...]
> Doing work in popFront instead of front is usually an anti-pattern,
> since it forces eager evaluation of the next element even when that
> element is never used. You should only do this if there's no
>
On 4/30/20 2:03 PM, Casey wrote:
Interesting. I'll take this into account. I was putting the work into
front because I didn't want to do the work until it was requested.
Putting the work in popFront makes more sense in some ways, but the fact
you have to call it before getting any records
On Thursday, 30 April 2020 at 16:21:05 UTC, Steven Schveighoffer
wrote:
I would say part of the issue is that you are doing all your
work in front and not popFront.
[...]
I'd say:
1. move your work to the popFront function (you then need to
call popFront once before returning the range in
On Thursday, 30 April 2020 at 16:21:05 UTC, Steven Schveighoffer
wrote:
I would say part of the issue is that you are doing all your
work in front and not popFront.
What happens is that Appender is a pointer-to-implementation
struct, and the compiler will allocate the first one shared
On 4/30/20 11:42 AM, Casey wrote:
On Thursday, 30 April 2020 at 13:23:25 UTC, Paul Backus wrote:
Using a default value like this means that it will be shared among all
instances of the struct. Instead, you should set `buff =
appender!string` in the constructor, so that each struct will have
On Thursday, 30 April 2020 at 15:42:03 UTC, Casey wrote:
I'll give it a try when I get back to it (fixing lint issues),
but are you sure that's the issue? In popFront, I recreate the
appender. So, the appender should be clear before the empty
check after it processes the last of the data
On Thursday, 30 April 2020 at 13:23:25 UTC, Paul Backus wrote:
Using a default value like this means that it will be shared
among all instances of the struct. Instead, you should set
`buff = appender!string` in the constructor, so that each
struct will have its own appender.
I'll give it a
On Thursday, 30 April 2020 at 13:23:25 UTC, Paul Backus wrote:
On Thursday, 30 April 2020 at 13:04:47 UTC, Casey wrote:
Here's a minimal code example that duplicates the issue:
import std.array, std.range, std.stdio, std.traits, std.string;
auto readStream(Range)(auto ref Range r) if
On Thursday, 30 April 2020 at 13:04:47 UTC, Casey wrote:
Here's a minimal code example that duplicates the issue:
import std.array, std.range, std.stdio, std.traits, std.string;
auto readStream(Range)(auto ref Range r) if
(isInputRange!(Unqual!Range))
{
struct StreamRange(Range)
On Wednesday, 29 April 2020 at 22:32:00 UTC, Simen Kjærås wrote:
I mean, it might be you messed up in posting this, but having
an empty popFront and expecting it to do something is a tad
optimistic.
I was just trying to get the example to a very minimal state. I
just added more descriptive
Here's a minimal code example that duplicates the issue:
import std.array, std.range, std.stdio, std.traits, std.string;
auto readStream(Range)(auto ref Range r) if
(isInputRange!(Unqual!Range))
{
struct StreamRange(Range)
{
alias R = Unqual!Range;
On Wednesday, 29 April 2020 at 20:43:20 UTC, Casey wrote:
void popFront()
{
}
I mean, it might be you messed up in posting this, but having an
empty popFront and expecting it to do something is a tad
optimistic.
Apart from that, it seems like
On Wednesday, 29 April 2020 at 20:43:20 UTC, Casey wrote:
So, I'm trying to run some tests and I had code that looks
similar to this:
[...]
I feel like I'm missing something obscure and it's driving me a
bit batty. Any clue as to why this is happening? I'd like to
not have to worry
So, I'm trying to run some tests and I had code that looks
similar to this:
unittest
{
auto range =
readStream(File("test_data/multiple.xml").byLine);
int count = 0;
while (!range.empty)
{
count++;
range.popFront();
}
19 matches
Mail list logo
