On 29.12.18 23:01, Steven Schveighoffer wrote:
> 
> I'm wondering if some generic "emulate N nested loops" with given stopping and starting conditions might be a useful addition for std.range or std.algorithm. I'm thinking of other looping algorithms like Floyd Warshall that might benefit from such building blocks.
> 
> -Steve

cartesianProduct suffices for Floyd-Warshall:

cartesianProduct(iota(n),iota(n),iota(n))
    .each!((k,i,j){ d[i][j]=min(d[i][j],d[i][k]+d[k][j]); });

For loops where nested ranges depend on outer indices, 'then' goes a long way. It is also easy to do something like:

mixin(comp!q{(i,j,k) | i in iota(n), j in iota(i), k in iota(j)})

This would expand to:

iota(n).then!(i=>iota(i).then!(j=>iota(j).map!(k=>tuple(i,j,k))))

(Of course, right now, tuples are somewhat inconvenient to use.)

On Saturday, 29 December 2018 at 22:01:58 UTC, Steven Schveighoffer wrote:
> On 12/29/18 4:29 AM, Walter Bright wrote:
>> http://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/
>> 
>> Time to show off your leet D skilz and see how good we can do it in D!
>
> Ugh, ranges really aren't a good fit for emulating nested loops, unless you write a specialized one.
>
> I tried my best, but it kind of sucks:
>
>     foreach(z, x, y;
>     iota(size_t.max)
>         .map!(a =>
>              zip(StoppingPolicy.shortest, a.repeat, iota(1, a)))
>         .joiner
>         .map!(t =>
>              zip(StoppingPolicy.shortest, t[0].repeat, t[1].repeat, iota(t[1], t[0])))
>         .joiner
>         .filter!(t => t[0]*t[0] == t[1]*t[1] + t[2]*t[2])
>         .take(100))
>     {
>         writeln(x, " ", y, " ", z);
>     }

Or if you can bear the closures

    iota(1, size_t.max)
        .map!(z => iota(1, z + 1)
              .map!(x => iota(x, z + 1)
                    .map!(y => tuple!("x", "y", "z")(x, y, z)))
              .joiner)
        .joiner
        .filter!(t => t.x^^2 + t.y^^2 == t.z^^2);

On Saturday, 29 December 2018 at 22:01:58 UTC, Steven Schveighoffer wrote:
> On 12/29/18 4:29 AM, Walter Bright wrote:
>> http://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/
>> 
>> Time to show off your leet D skilz and see how good we can do it in D!
>
> Ugh, ranges really aren't a good fit for emulating nested loops, unless you write a specialized one.
>
> I tried my best, but it kind of sucks:
>
>     foreach(z, x, y;
>     iota(size_t.max)
>         .map!(a =>
>              zip(StoppingPolicy.shortest, a.repeat, iota(1, a)))
>         .joiner
>         .map!(t =>
>              zip(StoppingPolicy.shortest, t[0].repeat, t[1].repeat, iota(t[1], t[0])))
>         .joiner
>         .filter!(t => t[0]*t[0] == t[1]*t[1] + t[2]*t[2])
>         .take(100))
>     {
>         writeln(x, " ", y, " ", z);
>     }

Isn't "StoppingPolicy.shortest" the default?

On Saturday, 29 December 2018 at 09:29:30 UTC, Walter Bright wrote:
> http://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/
>
> Time to show off your leet D skilz and see how good we can do it in D!

I'm on it. As I write, I'm timing (compile and run time) several C++, D, and Rust implementations and writing a blog post. I'm only on the 2nd implementation but D is winning... :)

I'm going to shamelessly steal Timon's range code in this thread and the generator one posted on reddit.

On Saturday, 29 December 2018 at 09:29:30 UTC, Walter Bright wrote:
> http://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/

It says:

> C++ compilation times have been a source of pain in every non-trivial-size codebase I’ve worked on. Don’t believe me? Try building one of the widely available big codebases (any of: Chromium, Clang/LLVM, UE4 etc will do). Among the things I really want out of C++, “solve compile times” is probably #1 on the list, and has been since forever.

I agree, it has been #1 problem with C++ in years, and only getting worse.

There is the theory (D builds fast) and the application (DUB often negate the advantage, you need to avoid templatitis).

On Sunday, 30 December 2018 at 12:22:01 UTC, John Colvin wrote:
> Or if you can bear the closures
>
>     iota(1, size_t.max)
>         .map!(z => iota(1, z + 1)
>               .map!(x => iota(x, z + 1)
>                     .map!(y => tuple!("x", "y", "z")(x, y, z)))
>               .joiner)
>         .joiner
>         .filter!(t => t.x^^2 + t.y^^2 == t.z^^2);

But this is still unreadable if you are not a D annointed range ninja.

On Sun, Dec 30, 2018 at 01:25:33PM +0000, Guillaume Piolat via Digitalmars-d wrote:
> On Saturday, 29 December 2018 at 09:29:30 UTC, Walter Bright wrote:
> > http://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/
> 
> It says:
> 
> > C++ compilation times have been a source of pain in every
> > non-trivial-size codebase I’ve worked on. Don’t believe me? Try
> > building one of the widely available big codebases (any of:
> > Chromium, Clang/LLVM, UE4 etc will do). Among the things I really
> > want out of C++, “solve compile times” is probably #1 on the list,
> > and has been since forever.
> 
> I agree, it has been #1 problem with C++ in years, and only getting worse.
> 
> There is the theory (D builds fast) and the application (DUB often
> negate the advantage, you need to avoid templatitis).

D theory sounds all good and all, but in practice you have warts like dub (one big reason I stay away from it -- though based on what Sonke said recently, performance may have improved since I last checked), std.regex (after the last big refactor, something Really Bad happened to its compile times -- it didn't used to be this bad!), std.format (a big hairball I haven't dared to look too deeply into), and a couple of others, like various recursive templates elsewhere in Phobos. And also std.uni's large templated internal tables, which may be (part of?) the common cause of compile-time slowdowns in std.format and std.regex.

There's also dmd's ridiculous memory usage policy, which is supposed to help compile times when you have ridiculous amounts of free RAM, but which causes anything from swap thrashing slowdowns to outright unusability on medium- to low-memory systems.


T

-- 
That's not a bug; that's a feature!

On Sunday, 30 December 2018 at 13:46:46 UTC, H. S. Teoh wrote:
> There's also dmd's ridiculous memory usage policy, which is supposed to help compile times when you have ridiculous amounts of free RAM, but which causes anything from swap thrashing slowdowns to outright unusability on medium- to low-memory systems.

Rainer an Martin Kinkelin have been working on that for LDC, they might upstream eventually.

On Sunday, 30 December 2018 at 13:46:46 UTC, H. S. Teoh wrote:
>
> D theory sounds all good and all, but in practice you have warts like dub (one big reason I stay away from it -- though based on what Sonke said recently, performance may have improved since I last checked), std.regex (after the last big refactor, something Really Bad happened to its compile times -- it didn't used to be this bad!), std.format (a big hairball I haven't dared to look too deeply into), and a couple of others, like various recursive templates elsewhere in Phobos. And also std.uni's large templated internal tables, which may be (part of?) the common cause of compile-time slowdowns in std.format and std.regex.
>
> There's also dmd's ridiculous memory usage policy, which is supposed to help compile times when you have ridiculous amounts of free RAM, but which causes anything from swap thrashing slowdowns to outright unusability on medium- to low-memory systems.
>
>
> T

Phobos has a few modules like this, but I believe that all of them should be fixable without help from the compiler, given enough effort.

On the other hand, hopefully soon we'll have the option to turn on the GC for the frontend. See: https://github.com/ldc-developers/ldc/pull/2916

As for Dub, we really ought to add a lower-level dependency graph interface for describing non-trivial builds. There are already a couple of (meta-)build systems written in D, so we have to come up with a good design and integrate one of them.

On Sunday, 30 December 2018 at 13:46:46 UTC, H. S. Teoh wrote:
> On Sun, Dec 30, 2018 at 01:25:33PM +0000, Guillaume Piolat via Digitalmars-d wrote:
>> On Saturday, 29 December 2018 at 09:29:30 UTC, Walter Bright wrote:
>> > http://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/
>> 
>> It says:
>> 
>> > C++ compilation times have been a source of pain in every
>> > non-trivial-size codebase I’ve worked on. Don’t believe me? Try
>> > building one of the widely available big codebases (any of:
>> > Chromium, Clang/LLVM, UE4 etc will do). Among the things I really
>> > want out of C++, “solve compile times” is probably #1 on the list,
>> > and has been since forever.
>> 
>> I agree, it has been #1 problem with C++ in years, and only getting worse.
>> 
>> There is the theory (D builds fast) and the application (DUB often
>> negate the advantage, you need to avoid templatitis).
>
> D theory sounds all good and all, but in practice you have warts like dub (one big reason I stay away from it -- though based on what Sonke said recently, performance may have improved since I last checked), std.regex (after the last big refactor, something Really Bad happened to its compile times -- it didn't used to be this bad!), std.format (a big hairball I haven't dared to look too deeply into), and a couple of others, like various recursive templates elsewhere in Phobos. And also std.uni's large templated internal tables, which may be (part of?) the common cause of compile-time slowdowns in std.format and std.regex.
>
> T

Perhaps we should implement CyberShadow's idea into the build infrastructure.  Works quite nicely with etsy statsd - see library from Burner.

https://blog.thecybershadow.net/2015/05/05/is-d-slim-yet/


Laeeth