Re: recursive template expansion: Why does this not compile?

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, March 21, 2018 00:47:18 Ontonator via Digitalmars-d-learn 
wrote:
> The following code does not compile:
> > void main() {}
> >
> > class SuperClass {}
> >
> > class TemplatedClass(T : SuperClass) {}
> >
> > class A : SuperClass {
> >
> > alias T = TemplatedClass!B;
> >
> > }
> >
> > class B : SuperClass {
> >
> > alias T = TemplatedClass!C;
> >
> > }
> >
> > class C : SuperClass {}
>
> It gives the error:
> > test.d(12): Error: class `test.TemplatedClass(T : SuperClass)`
> > recursive template expansion
> > test.d(12):while looking for match for
> > TemplatedClass!(C)
>
> The aliases do not have to be aliases, as long as there is some
> reference to the class (e.g. method and variable declarations
> also work). What exactly is the reason for this error?

I'm not sure exactly what's happening, since I'm not very familiar with the
exactly how template specializations are defined, but the problem clearly
relates to the fact that you used a template specialization instead of a
template constraint. If you change TemplatedClass to

class TemplatedClass(T)
if(is(T : SuperClass))
{}

then the code compiles.

- Jonathan M Davis

recursive template expansion: Why does this not compile?

[Ontonator via Digitalmars-d-learn]

The following code does not compile:

void main() {}

class SuperClass {}

class TemplatedClass(T : SuperClass) {}

class A : SuperClass {
alias T = TemplatedClass!B;
}

class B : SuperClass {
alias T = TemplatedClass!C;
}

class C : SuperClass {}


It gives the error:
test.d(12): Error: class `test.TemplatedClass(T : SuperClass)` 
recursive template expansion
test.d(12):while looking for match for 
TemplatedClass!(C)


The aliases do not have to be aliases, as long as there is some 
reference to the class (e.g. method and variable declarations 
also work). What exactly is the reason for this error?

Re: Incomprehensible error message

[Adam D. Ruppe via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 23:45:20 UTC, H. S. Teoh wrote:
 The tricky part is, who's going to do the work of going 
through *all* of dmd's error messages and rewriting them with 
said metadata.


We did it for the stupid syntax highlighting thing... and this 
has bigger win, though it is also more work than just adding `` 
around it.


 It would seem to me that a solution that can be implemented 
gradually is more likely to be adopted.


The beauty of XML is that it is reasonably easy to do gradually 
since it is a marked up string rather than a whole new format. On 
the display side, it can even detect if(str[0] == '<') assume it 
is xml, otherwise assume it is plain text. User-side ides can do 
it as well as the compiler's top-level presentation layer. Or the 
existing error() function can add "" and encode the stuff, 
and a new detailedError function does more detail.


xml is also extensible to add more info later when we decide. It 
really is quite elegant for marking up a text base with more 
metadata...


 E.g. if we can somehow work with the existing format of error 
messages and extract some useful info from them, perhaps 
reformat substrings that match certain known patterns, then we 
can gradually migrate all error messages to a particular format 
that will eventually serve as the intermediate metadata 
encoding.


Well, a lot of info is lost by the toChars not putting out as 
much info as it could. So working with existing messages still 
needs changes on the generation side to improve it. But we can 
add info as we go.

Re: Incomprehensible error message

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Mar 20, 2018 at 11:05:59PM +, Adam D. Ruppe via Digitalmars-d-learn 
wrote:
> On Tuesday, 20 March 2018 at 21:18:01 UTC, H. S. Teoh wrote:
> > Which means error messages would need to be constructed as an
> > abstract object that the error message printer can then inspect to
> > determine which symbol(s) should be FQNs.
> 
> I've talked before about XML error messages. I'd actually like them to
> literally be xml, but even if they aren't the same principle works -
> pack the error messages with a lot of metadata when they are
> generated, then trim that at a higher level to make it more
> presentable (ideally, that higher level may be the ide, but for a
> console run the compiler might have to do it).

That's not a bad idea, and pretty close to what I have in mind.  The
tricky part is, who's going to do the work of going through *all* of
dmd's error messages and rewriting them with said metadata.  It would
seem to me that a solution that can be implemented gradually is more
likely to be adopted.  E.g. if we can somehow work with the existing
format of error messages and extract some useful info from them, perhaps
reformat substrings that match certain known patterns, then we can
gradually migrate all error messages to a particular format that will
eventually serve as the intermediate metadata encoding.

Any proposed solution that requires a one-off rewriting of every single
error message in dmd is unlikely to fly, IMO.


T

-- 
There are 10 kinds of people in the world: those who can count in binary, and 
those who can't.

Re: Incomprehensible error message

[Adam D. Ruppe via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 21:18:01 UTC, H. S. Teoh wrote:
 Which means error messages would need to be constructed as an 
abstract object that the error message printer can then inspect 
to determine which symbol(s) should be FQNs.


I've talked before about XML error messages. I'd actually like 
them to literally be xml, but even if they aren't the same 
principle works - pack the error messages with a lot of metadata 
when they are generated, then trim that at a higher level to make 
it more presentable (ideally, that higher level may be the ide, 
but for a console run the compiler might have to do it).

Re: Incomprehensible error message

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Mar 20, 2018 at 10:04:30PM +0100, Jacob Carlborg via 
Digitalmars-d-learn wrote:
> On 2018-03-19 19:03, H. S. Teoh wrote:
> 
> > Yeah, the compiler really ought to be outputting FQNs in error
> > messages, since otherwise you get baffling A != A messages.  Though
> > outputting FQNs everywhere has the tendency of bloating error
> > messages to unreadable lengths, esp. when templates are involved.
> > :-(  (Though fortunately, no templates are involved in this case.)
> 
> The compiler could output the FQN names only when the non qualified
> names are the same. Should hopefully reduce the bloated error
> messages.
[...]

Yeah, I thought about that too, but then it wouldn't be easy to
implement, since you wouldn't be able to easily predict whether or not
to use an FQN name when you've detected an error and just need to print
an error and bailout.  It needs to be automated in order to be
maintainable (nobody wants to go through thousands of compiler errors
and insert complex logic to decide which symbol(s) should be FQN).
Which means error messages would need to be constructed as an abstract
object that the error message printer can then inspect to determine
which symbol(s) should be FQNs.

Either way, it will require a lot of effort to pull off.


T

-- 
For every argument for something, there is always an equal and opposite 
argument against it. Debates don't give answers, only wounded or inflated egos.

Re: Packages and module import

[Jacob Carlborg via Digitalmars-d-learn]

On 2018-03-19 18:29, Russel Winder wrote:

I had assumed that a directory of modules was a package. So for
example:

A/a.d
A/b.d

were two modules in package A. Especially given there is a module
statement at the beginning of each module:

A/a.d has  module A.a;
A/b.d has  module A.b;

Now A.b needs to access something from A.a. I had assumed that the
import should be fully qualified. So in A.b.d:

import A.a: thing;

This all works when building the library.


ldc2 -of=Build/Release/libdvbv5_d.so -shared -defaultlib=phobos2-ldc 
Build/Release/source/libdvbv5_d/linux_dmx.o 
Build/Release/source/libdvbv5_d/dvb_v5_std.o 
Build/Release/source/libdvbv5_d/dvb_frontend.o 
Build/Release/source/libdvbv5_d/dvb_log.o 
Build/Release/source/libdvbv5_d/dvb_demux.o 
Build/Release/source/libdvbv5_d/dvb_fe.o 
Build/Release/source/libdvbv5_d/dvb_file.o 
Build/Release/source/libdvbv5_d/dvb_scan.o 
Build/Release/source/libdvbv5_d/dvb_sat.o -L-ldruntime-ldc


However when trying to build the unit-tests:


ldc2 -I=source -unittest --main -of=Build/Test/libdvbv5_d 
source/libdvbv5_d/linux_dmx.d source/libdvbv5_d/dvb_v5_std.d 
source/libdvbv5_d/dvb_frontend.d source/libdvbv5_d/dvb_log.d 
source/libdvbv5_d/dvb_demux.d source/libdvbv5_d/dvb_fe.d 
source/libdvbv5_d/dvb_file.d source/libdvbv5_d/dvb_scan.d 
source/libdvbv5_d/dvb_sat.d
source/libdvbv5_d/dvb_demux.d(35): Error: module linux_dmx from file 
source/libdvbv5_d/linux_dmx.d must be imported with 'import linux_dmx;'


Am I just missing something simple?


Not sure if this will help, but are you aware that DStep can add a 
package to the module declaration using "--package"?


--
/Jacob Carlborg

Re: Incomprehensible error message

[Jacob Carlborg via Digitalmars-d-learn]

On 2018-03-19 19:03, H. S. Teoh wrote:


Yeah, the compiler really ought to be outputting FQNs in error messages,
since otherwise you get baffling A != A messages.  Though outputting
FQNs everywhere has the tendency of bloating error messages to
unreadable lengths, esp. when templates are involved. :-(  (Though
fortunately, no templates are involved in this case.)


The compiler could output the FQN names only when the non qualified 
names are the same. Should hopefully reduce the bloated error messages.


--
/Jacob Carlborg

Re: Slow start up time of runtime (correction: Windows real-time protection)

[rumbu via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 16:56:59 UTC, Dennis wrote:

On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:

On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote:
I suspect you are seeing the Windows antivirus hitting you. D 
runtime starts up in a tiny fraction of a second, you 
shouldn't be noticing it.


You're totally right, disabling real-time protection makes a 
massive difference. I always found a second exceptionally long 
for a runtime to initialize, but I couldn't think of any other 
differences between a simple dmd-compiled program and a simple 
dmc-compiled program.


On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:
 I betcha you'll see this delay (and a similar one on dmd 
itself, your compiles could be running at half-speed with this 
too)


Definitely. I've tested how long tools take to simply print 
their help text: for the first time with virus scan, second 
time with virus scan and without any real-time protection. D 
tools seem to get the longest delay.


First   Second  No protection (miliseconds)
dmc 84  52  16
dmd 2400120024
dub 2300110025
ldc 4500180 30
gcc 240 100 18


On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:
I don't know why the antivirus picks on D so much, but on my 
box it does and it sounds like it is on yours too. BTW that 
real time check box likes to keep turning itself on... so the 
slowness will keep coming back.


Typical Windows... It keeps turning on the Windows update 
service too.


This now leaves the question what's the best way to mitigate 
this, because I would gladly get rid of the second of delay any 
time I invoke dmd, ldc or dub as well as my own applications.


I cannot guarantee that this is the cause, but I observed that 
Bitdefender is very picky with Intel OMF format. I made a lot of 
complaints about this (it was impossible to debug a intel omf 
compiled exe with Bitdefender installed and the advice received 
from Bitdefender was to compile my executables in mscoff format. 
That's how my problem disappeared. Windows Defender incorporated 
last year Bitdefender scanning technology, maybe this is an 
explanation.

Re: Slow start up time of runtime (correction: Windows real-time protection)

[Dennis via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:

On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote:
I suspect you are seeing the Windows antivirus hitting you. D 
runtime starts up in a tiny fraction of a second, you shouldn't 
be noticing it.


You're totally right, disabling real-time protection makes a 
massive difference. I always found a second exceptionally long 
for a runtime to initialize, but I couldn't think of any other 
differences between a simple dmd-compiled program and a simple 
dmc-compiled program.


On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:
 I betcha you'll see this delay (and a similar one on dmd 
itself, your compiles could be running at half-speed with this 
too)


Definitely. I've tested how long tools take to simply print their 
help text: for the first time with virus scan, second time with 
virus scan and without any real-time protection. D tools seem to 
get the longest delay.


First   Second  No protection (miliseconds)
dmc 84  52  16
dmd 2400120024
dub 2300110025
ldc 4500180 30
gcc 240 100 18


On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:
I don't know why the antivirus picks on D so much, but on my 
box it does and it sounds like it is on yours too. BTW that 
real time check box likes to keep turning itself on... so the 
slowness will keep coming back.


Typical Windows... It keeps turning on the Windows update service 
too.


This now leaves the question what's the best way to mitigate 
this, because I would gladly get rid of the second of delay any 
time I invoke dmd, ldc or dub as well as my own applications.

Re: How to build static linked executable

[Jacob Carlborg via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 10:37:55 UTC, zunkree wrote:


So, how to build static binary for macOS?


I don't see a need to do that. I build static binaries on Linux 
because they work across all distros and all versions. But for 
macOS, there are no distros. For supporting multiple versions, or 
rather an older version than you're building on, you can use the 
"-macosx_version_min" linker flag. See [1] for an example.


If you really want a static binary, I think it's possible if 
you're calling the kernel directly (I think Go can do this). But 
then most of D would not work, since it builds on the C standard 
library.


[1] 
https://github.com/jacob-carlborg/dstep/blob/19a5ddb8ad3f44b3445c89840155bb7cd1ee44b7/dub.json#L20


--
/Jacob Carlborg

Re: Slow start up time of runtime

[HeiHon via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:
Go into the Windows security center and uncheck the real time 
virus check protection. I betcha you'll see this delay (and a 
similar one on dmd itself, your compiles could be running at 
half-speed with this too) disappear and everything will seem a 
LOT faster.


I also noticed slow startup times for freshly compiled D programs.
And yes, I can verify that it's the Windows Defender's realtime 
scan.
I switched it off (Windows 10) and dmd itself and the compiled D 
program started just as fast as they should.
It gets better (with realtime scan enabled) when you compile your 
programs with

dmd -O -release -m64 app.d

Re: Is there a way to pipeline program with random-access ranges in C#?

[Kagamin via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 15:06:14 UTC, Dukc wrote:

Won't quite do it, because that would not iterate backwards.


Linq has no chunking, so you would need to write it, maybe 
similar to SelectMany, but with the opposite meaning.


public static IEnumerable> Enumerate(this 
IEnumerable range)
{   return range.Zip(Enumerable.Range(0, int.MaxValue), (x, y) 
=> new Sequence(x, y));

}


If you want to have index, there's 
https://msdn.microsoft.com/en-us/library/bb534869(v=vs.110).aspx

Re: Is there a way to pipeline program with random-access ranges in C#?

[Dukc via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 08:05:14 UTC, Kagamin wrote:

On Monday, 19 March 2018 at 17:33:31 UTC, Dukc wrote:

public static int Foo(int[] input)
{   int result = 10;
for (int i = input.Length / 4; i >= 0; i -= 4)
{   int sum = 0;
for (int j = i; j < i +4 && j < input.Length; j++) sum 
+= input[j];

sum *= i;
result = (result + sum) / 2;
}
return result;
}


Looks like you need to partition, select, aggregate and another 
aggregate.


Won't quite do it, because that would not iterate backwards.

But anyway, I made this extension function today which solves 
most of my problems, albeit not that one above:


public static IEnumerable> Enumerate(this 
IEnumerable range)
{   return range.Zip(Enumerable.Range(0, int.MaxValue), (x, y) => 
new Sequence(x, y));

}

(Of course, were I compiling to .net framework instead of 
JavaScript I would have to use Tuple or ValueTuple instead of 
Sequence)

Re: Slow start up time of runtime

[Adam D. Ruppe via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote:

I suppose initializing the runtime takes a lot of time.


I suspect you are seeing the Windows antivirus hitting you. D 
runtime starts up in a tiny fraction of a second, you shouldn't 
be noticing it.


Go into the Windows security center and uncheck the real time 
virus check protection. I betcha you'll see this delay (and a 
similar one on dmd itself, your compiles could be running at 
half-speed with this too) disappear and everything will seem a 
LOT faster.


I don't know why the antivirus picks on D so much, but on my box 
it does and it sounds like it is on yours too. BTW that real time 
check box likes to keep turning itself on... so the slowness will 
keep coming back.

Re: Slow start up time of runtime

[bauss via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 10:46:11 UTC, Dennis wrote:

On Tuesday, 20 March 2018 at 10:20:55 UTC, Dennis wrote:

On Tuesday, 20 March 2018 at 09:51:09 UTC, bauss wrote:
Besides if it was and it took 1 second to startup, then it 
wouldn't matter in practice with an actual application.


This is not concerning for large applications indeed. But say, 
I want to implement my own `dir` (= `ls` on Unix) in D. Would 
you want to use it if it took a full second every time you 
wanted to quickly view a folder's contents?


To give some more context, I've been using some of the digital 
mars utilities and I admire their speed. A `grep -r "goto" *.d` 
could find and scan 1.7 MB of d-source files in 190ms, way 
before my D hello-world was even able to enter main. As far I 
know, these are just C programs. I wonder if I could make such 
fast utilities in D, or whether (idiomatic) D is not the right 
tool for this and I should use (better)C instead.


Have you tried other applications that doesn't just print and see 
if that matters?


Try to write to a file instead of the standard output and see if 
that makes any difference between each compilation unit.


Also remember that you don't compile with dmd for runtime speed, 
but compilation speed. For runtime speed you want to use ldc, 
since it optimizes code way better.

Re: Slow start up time of runtime

[bauss via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 12:07:12 UTC, bauss wrote:

On Tuesday, 20 March 2018 at 10:46:11 UTC, Dennis wrote:

On Tuesday, 20 March 2018 at 10:20:55 UTC, Dennis wrote:

On Tuesday, 20 March 2018 at 09:51:09 UTC, bauss wrote:
Besides if it was and it took 1 second to startup, then it 
wouldn't matter in practice with an actual application.


This is not concerning for large applications indeed. But 
say, I want to implement my own `dir` (= `ls` on Unix) in D. 
Would you want to use it if it took a full second every time 
you wanted to quickly view a folder's contents?


To give some more context, I've been using some of the digital 
mars utilities and I admire their speed. A `grep -r "goto" 
*.d` could find and scan 1.7 MB of d-source files in 190ms, 
way before my D hello-world was even able to enter main. As 
far I know, these are just C programs. I wonder if I could 
make such fast utilities in D, or whether (idiomatic) D is not 
the right tool for this and I should use (better)C instead.


Have you tried other applications that doesn't just print and 
see if that matters?


Try to write to a file instead of the standard output and see 
if that makes any difference between each compilation unit.


Also remember that you don't compile with dmd for runtime 
speed, but compilation speed. For runtime speed you want to use 
ldc, since it optimizes code way better.


To add on to this.

Typically dmd is better during development, ldc is better during 
deployment and release.

Re: How to build static linked executable

[David Nadlinger via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 10:37:55 UTC, zunkree wrote:

On Sunday, 18 March 2018 at 14:36:04 UTC, Jacob Carlborg wrote:

FYI, -static is not support on macOS.


So, how to build static binary for macOS?


Static binaries aren't really supported by Apple (anymore).

What do you need it for?

 — David

Re: Slow start up time of runtime

[David Nadlinger via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote:
Are there ways to reduce this to below 0.1s, or should I just 
leave idiomatic D and make a betterC program?


The best solution would be to profile the startup process and 
file a bug accordingly. ;)


 — David

Re: Slow start up time of runtime

[Dennis via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 10:20:55 UTC, Dennis wrote:

On Tuesday, 20 March 2018 at 09:51:09 UTC, bauss wrote:
Besides if it was and it took 1 second to startup, then it 
wouldn't matter in practice with an actual application.


This is not concerning for large applications indeed. But say, 
I want to implement my own `dir` (= `ls` on Unix) in D. Would 
you want to use it if it took a full second every time you 
wanted to quickly view a folder's contents?


To give some more context, I've been using some of the digital 
mars utilities and I admire their speed. A `grep -r "goto" *.d` 
could find and scan 1.7 MB of d-source files in 190ms, way before 
my D hello-world was even able to enter main. As far I know, 
these are just C programs. I wonder if I could make such fast 
utilities in D, or whether (idiomatic) D is not the right tool 
for this and I should use (better)C instead.

Re: How to build static linked executable

[zunkree via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 14:36:04 UTC, Jacob Carlborg wrote:

On 2018-03-17 16:42, Seb wrote:


Yes, use -static

Here's how we build the DTour: 
https://github.com/dlang-tour/core/blob/master/dub.sdl


FYI, -static is not support on macOS.


So, how to build static binary for macOS?

Re: How to build static linked executable

[zunkree via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 15:42:06 UTC, Seb wrote:

On Saturday, 17 March 2018 at 14:44:42 UTC, zunkree wrote:

Hi,

Is there a way to build static linked executable with dub for 
vibe-d based app?


Regards,
zunkree


Yes, use -static

Here's how we build the DTour: 
https://github.com/dlang-tour/core/blob/master/dub.sdl


Thank you very much.

Re: Slow start up time of runtime

[Dennis via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 09:51:09 UTC, bauss wrote:
Besides if it was and it took 1 second to startup, then it 
wouldn't matter in practice with an actual application.


This is not concerning for large applications indeed. But say, I 
want to implement my own `dir` (= `ls` on Unix) in D. Would you 
want to use it if it took a full second every time you wanted to 
quickly view a folder's contents?


On Tuesday, 20 March 2018 at 09:51:09 UTC, bauss wrote:
Without actual compiler versions, compiler flags and example 
code then it's pretty much impossible to tell what's slow.


```
import core.stdc.stdio: printf;

int main() {
return printf("hello world");
}
```
Compiling with `dmd helloworld_printf.d` or `dmd -release -O 
-inline helloworld_printf.d` doesn't make a difference here: 
`Measure-Command {./helloworld_printf}` reports ~1.1s in any 
case.  I'm using 2.079 but I doubt this is a regression.


betterC version:
```
import core.stdc.stdio: printf;

extern(C) int main() {
return printf("hello world");
}
```
`dmd helloworld_betterc.d -betterC`
`ldc2 helloworld_betterc.d -betterC`

I now notice that without the -betterC flag it's also 0.05s. So I 
suppose defining a `_d_run_main` instead of a `extern(C) main` is 
causing the slow startup time.

Re: Slow start up time of runtime

[bauss via Digitalmars-d-learn]

On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote:

Simply running a "hello world.exe" takes, on my pc:

1.12s When compiled with dmd
0.62s When compiled with ldc
0.05s When compiled with dmc (C program) or dmd/ldc as a 
-betterC program


I suppose initializing the runtime takes a lot of time. When 
making a simple command line utility, half a second of delay is 
highly undesirable.


Are there ways to reduce this to below 0.1s, or should I just 
leave idiomatic D and make a betterC program?


It's not necessarily the runtime that's slow.

Besides if it was and it took 1 second to startup, then it 
wouldn't matter in practice with an actual application.


Besides there could be a lot other factors.

Without actual compiler versions, compiler flags and example code 
then it's pretty much impossible to tell what's slow.


For me it's certainly not that slow with dmd.

Slow start up time of runtime

[Dennis via Digitalmars-d-learn]

Simply running a "hello world.exe" takes, on my pc:

1.12s When compiled with dmd
0.62s When compiled with ldc
0.05s When compiled with dmc (C program) or dmd/ldc as a -betterC 
program


I suppose initializing the runtime takes a lot of time. When 
making a simple command line utility, half a second of delay is 
highly undesirable.


Are there ways to reduce this to below 0.1s, or should I just 
leave idiomatic D and make a betterC program?

Re: Is there a way to pipeline program with random-access ranges in C#?

[Kagamin via Digitalmars-d-learn]

On Monday, 19 March 2018 at 17:33:31 UTC, Dukc wrote:

public static int Foo(int[] input)
{   int result = 10;
for (int i = input.Length / 4; i >= 0; i -= 4)
{   int sum = 0;
for (int j = i; j < i +4 && j < input.Length; j++) sum 
+= input[j];

sum *= i;
result = (result + sum) / 2;
}
return result;
}


Looks like you need to partition, select, aggregate and another 
aggregate.