I start to understand: A (lazy) range is something like a
voucher: byChunk() does not provide the data immediately, but
only a voucher to hand you a chunk (an array of 2 bytes in my
example above) a time. This voucher is passed to joiner(), which
keeps that voucher and hands me out a new
On Friday, 5 July 2019 at 04:04:13 UTC, Jonathan M Davis wrote:
On Thursday, July 4, 2019 2:49:18 AM MDT zoujiaqing via
Digitalmars-d-learn wrote:
LDC on FreeBSD working fine?
It should work on FreeBSD 11. It almost certainly doesn't work
on 12 because of bindings issues that still need to
On Saturday, 6 July 2019 at 18:17:26 UTC, Jonathan M Davis wrote:
take _always_ consumes the range that it's given
not if it hasSlicing. see
http://dpldocs.info/experimental-docs/source/std.range.d.html#L2015
but yeah otherwise i agree with you
On Saturday, July 6, 2019 12:17:26 PM MDT Jonathan M Davis via Digitalmars-
d-learn wrote:
> On Saturday, July 6, 2019 8:12:36 AM MDT berni via Digitalmars-d-learn
>
> wrote:
> > Now it's getting weird. Meanwhile I encountered, that take()
> > sometimes consumes and sometimes not. Where can I
On Saturday, 6 July 2019 at 12:33:00 UTC, berni wrote:
Now I found this:
https://forum.dlang.org/thread/eobdqkkczquxoepst...@forum.dlang.org
Seems to be intentional, that this doesn't work. In my case I'm
able to move d() into the outer struct...
You'll need a pointer to the outer struct,
On Saturday, July 6, 2019 8:12:36 AM MDT berni via Digitalmars-d-learn
wrote:
> Now it's getting weird. Meanwhile I encountered, that take()
> sometimes consumes and sometimes not. Where can I learn, what is
> the reason behind this behavior? And how can I handle this?
take _always_ consumes the
On Saturday, 6 July 2019 at 14:48:04 UTC, Adam D. Ruppe wrote:
[...]
So this is a case of input range behavior - always consuming
the underlying file - combined with buffering of two elements
at once, leaving 5,6 behind, and the reuse of the buffer
meaning you see that 5,6 again on the next
On Saturday, 6 July 2019 at 14:40:23 UTC, berni wrote:
.byChunk(BUFFER_SIZE)
byChunk is defined to reuse its buffer between calls.
http://dpldocs.info/experimental-docs/std.stdio.byChunk.1.html#examples
This means previous contents are overwritten when you advance.
When I now
On Saturday, 6 July 2019 at 14:12:36 UTC, berni wrote:
Meanwhile I encountered, that take() sometimes consumes and
sometimes not.
It depends on what you're passing.
So take is defined as just getting the first N elements from the
given range. So what happens next depends on what it is
A small example showing this strange behaviour:
import std.stdio;
import std.algorithm.iteration;
import std.range;
enum BUFFER_SIZE = 1024;
void main(string[] args)
{
auto a = (new File(args[1]))
.byChunk(BUFFER_SIZE)
.joiner;
writeln(a.take(5));
writeln(a);
}
Using
Now it's getting weird. Meanwhile I encountered, that take()
sometimes consumes and sometimes not. Where can I learn, what is
the reason behind this behavior? And how can I handle this?
On Saturday, 6 July 2019 at 12:10:13 UTC, berni wrote:
On Saturday, 6 July 2019 at 11:48:51 UTC, a11e99z wrote:
Maybe I need to explain, what I dislike with this approach:
take() calls popFront n times and drop() calls popFront another
n times giving a total of 2n times (depending on the
Now I found this:
https://forum.dlang.org/thread/eobdqkkczquxoepst...@forum.dlang.org
Seems to be intentional, that this doesn't work. In my case I'm
able to move d() into the outer struct...
On Saturday, 6 July 2019 at 11:48:42 UTC, berni wrote:
On Thursday, 4 July 2019 at 17:00:33 UTC, Q. Schroll wrote:
The prime example is printing the comma when printing a list:
There is one between any two elements, but neither is one at
front or behind the last one.
If it is just for
On Friday, 5 July 2019 at 19:56:54 UTC, ag0aep6g wrote:
It works when you pass an actual callable instead, e.g. a
lambda:
p.map!(a => a[column]).maxElement.writeln;
On Friday, 5 July 2019 at 20:22:14 UTC, dwdv wrote:
Furthermore, Samir, the parameter `a` can be renamed to
whatever you
On Saturday, 6 July 2019 at 11:48:51 UTC, a11e99z wrote:
sure
auto take_consuming( R )( ref R r, int cnt ) {
auto tmp = r.take( cnt ).array;
r = r.drop( cnt );
return tmp;
}
don't thank
Doesn't look like what I'm looking for, as it is exactly the same
I allready found.
Maybe I
On Saturday, 6 July 2019 at 11:20:50 UTC, berni wrote:
I want to copy the first n items of a range to an array, I came
up with this now:
data = r.take(n).array;
This works partly, because the values of r are not consumed. So
I have to call afterwards:
r = r.drop(n);
Now I wonder, if it is
On Thursday, 4 July 2019 at 17:00:33 UTC, Q. Schroll wrote:
The prime example is printing the comma when printing a list:
There is one between any two elements, but neither is one at
front or behind the last one.
If it is just for printing commas in between, you can use
range.join(", ")
struct A
{
void c() {}
struct B
{
void d()
{
c();
}
}
}
When compiling this with rdmd I get the message: "Error: this for
c needs to be type A not type B". Is there a way to call c from d?
I want to copy the first n items of a range to an array, removing
these items from the range.
This works:
foreach (i;0..n)
{
data ~= r.front;
r.popFront();
}
but looks a little bit arkward.
I came up with this now:
data = r.take(n).array;
This works partly, because the values of
On Friday, 5 July 2019 at 23:05:32 UTC, Jonathan M Davis wrote:
Yes, I was wondering why the compiler doesn't statically
allocate it automatically as an optimization.
It would have to be set up to store the literal somewhere else.
I was thinking the read-only data segment.
Certainly, it
On 06.07.19 01:12, Patrick Schluter wrote:
On Friday, 5 July 2019 at 23:08:04 UTC, Patrick Schluter wrote:
On Thursday, 4 July 2019 at 10:56:50 UTC, Nick Treleaven wrote:
immutable(int[]) f() @nogc {
return [1,2];
}
[...]
and it cannot optimize it away because it doesn't know what the
22 matches
Mail list logo
