On Friday, 13 December 2013 at 16:40:13 UTC, Manu wrote:
> No, as in, people 'not really' write D code that way, or no as in, it
> doesn't look like java, except that it does, because only it and javascript
> have idiomatic egyptian braces... ;)

I write all my D code that way, except that which is merged to Phobos (which is still written "Egyptian" and I have to later format it).

You'll hate vibe.d since it seems to be the chaos you don't want:
https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/inet/webform.d

Personally I don't care, reading, I won't notice. However I can't write the code any other way without spending lots of time on formatting. And I prefer the Egyptian.

On Friday, 13 December 2013 at 15:58:43 UTC, dennis luehring wrote:
> please revert - it looks terrible newbie like, no one except Rikki writes it like this
>
> it makes absolutely no sense to pseudo-scope these enums and variable declarations, they do not share anything except the type AND that is not enough for pseudo-scope

I thought it seemed useful in that it'd make it easier to e.g. change all those doubles to floats. If it's generally considered unidiomatic D, however, then I can revert it.

On Friday, 13 December 2013 at 16:06:10 UTC, Manu wrote:
> Is it idiomatic to use egyptian braces in D? I've never seen D code written
> this way... looks like Java.

It's just the style I've been using in the benchmark; even the lisp implementations use it. I think it's due to the influence of programming in Go, where that style is mandated (the compiler throws an error if you put a newline before the {).

> You have a lot of globals, and they're all TLS. That seems inefficient, and
> potentially incorrect if there were threads.

You're right; I just copied the C code, I didn't consider that it being TLS in D might reduce efficiency. I don't mind it not being threadsafe, as I don't have any intention to parallelise the benchmark, due to most of the time being spent on rendering that can't be parallelised.

> Why do you build the vertex array from literal data at runtime? Why not
> just initialise the array?
> It's a static array, so it's not allocated at runtime, so it shouldn't be
> any different. You'd probably save a lot of LOC to initialise the array,
> perhaps better for clarity. It should probably also be immutable?

I left initialising the array to runtime for clarity; I think it's easier to read that way than if it's just declared as a really long array literal. I'd be happy to populate the array at compile time though, if there's an easy way to change the initialisation functions to run at compile time. Making it immutable is a good idea, although it wouldn't help performance as the array is only read once, when it's being fed into the vertex buffer.

> Those integer for loops might be nicer as: foreach(i; 0 .. n)

Updated it to use that. I was wondering how to do foreach over a numerical range in D; now I know, thanks.

> I'm not personally in the camp that agrees:
>   double
>     x = 0,
>     y = 10,
>     z = 15;
> is a good thing... but each to their own :)

I just assumed it'd be better as it allows for easier refactoring (only need to change 'double' one).

> Why are you using 'double' in realtime software? That's weird isn't it?
> Granted, it will make no difference on x86, but I'd never personally do
> this for portability reasons.

Because in my previous benchmarks I've found it performs no differently from float on this system, and because it's a direct port of the C implementation, where I paranoidly used double in order to avoid precision errors if it's ever run on a system where float is 16 bit. It also makes for fairer comparison with the Go code, which uses 64 bit floats as the standard maths library doesn't support f32s.

> But generally looks fine. Any opengl code is naturally going to look C-ish
> by nature. And yes, as you said, it's not really a very good benchmark,
> since you're really benchmarking the GPU (and the legacy fallback
> non-shader pipeline at that) ;) .. The mainloop barely does anything, and
> has very few iterations.

Yep. I tried with shaders but it didn't really improve the speed at all, as most of the time's spent rendering, so I'm using the legacy pipeline for convenience.

> Nitpick: I think properness would have you update the velocity before the
> position, or you'll always run 1 frame behind.
> There are a lot more really minor performance hazards that I'd never let
> slip if they were invoked in hot loops, but they won't make any difference
> here.

You're right; I've reordered doWind, checkColls and movePts. Thanks for all the tips!

On Friday, 13 December 2013 at 14:45:49 UTC, qznc wrote:
> Use std.algorithm instead of for-loops for sum calculation:
>
> sum = reduce!"a + b"(0, frames);

I tried 'auto sum = reduce!"a + b"(0, frames);' but I get an error:

algorithm.d(782): Error: cannot implicitly convert expression (binaryFun(result._expand_field_0, elem)) of type double to int
std/conv.d(3606): Error: cannot implicitly convert expression (_param_1) of type double to int
algorithm.d(794): Error: template instance std.conv.emplace!(int, double) error instantiating
D.d(308):        instantiated from here: reduce!(int, double[25000LU])

> Mmm, I prefer C braces for this reason.

There is no such thing as "C-braces" or idiomatic C. C is defined
by anarchy and chaos. The reason old C-code (and guides) have
braces on the next line for function calls is that the type was
specified under the parameter-list in old-style C.

http://en.wikipedia.org/wiki/Indent_style

Fixed rules for whitespace leads to poor legibility, creating legible
layout is a context sensitive design problem.

No wonder the D-language is stuck in a state of poor usability
with discussions like this eating all the bandwidth…

And, why, why, why would anyone think that it is a good idea to
use the boolean negate-operator for templates? Talk about making
my eyes sore! D has a large heap of usability and inconsistency
problems that makes freedom-of-whitespace a drop in a biiiig
ocean. Get real, you need to focus on real challenges if you want
D to take off!

(back to lurking)

I only made the point (among a bunch of other points!) because I wondered
if it was worth presenting consistency in D code intended for public
scrutiny. It's all good, it's settled now. It's not my fault, or my intent,
that the most trivial point in my list of comments is the one that
apparently stimulated the most discussion... :/
On 14 Dec 2013 14:00, <&quot;Ola Fosheim Grøstad\&quot; &
lt;ola.fosheim.grostad+dlang@gmail.com&gt;&quot;@puremagic.com> wrote:

> Mmm, I prefer C braces for this reason.
>>
>
> There is no such thing as "C-braces" or idiomatic C. C is defined by anarchy and chaos. The reason old C-code (and guides) have braces on the next line for function calls is that the type was specified under the parameter-list in old-style C.
>
> http://en.wikipedia.org/wiki/Indent_style
>
> Fixed rules for whitespace leads to poor legibility, creating legible layout is a context sensitive design problem.
>
> No wonder the D-language is stuck in a state of poor usability with discussions like this eating all the bandwidth…
>
> And, why, why, why would anyone think that it is a good idea to use the boolean negate-operator for templates? Talk about making my eyes sore! D has a large heap of usability and inconsistency problems that makes freedom-of-whitespace a drop in a biiiig ocean. Get real, you need to focus on real challenges if you want D to take off!
>
> (back to lurking)
>

On Saturday, 14 December 2013 at 03:55:29 UTC, Ola Fosheim Grøstad wrote:
> And, why, why, why would anyone think that it is a good idea to
> use the boolean negate-operator for templates? Talk about making
> my eyes sore!

I have to wonder about this point. What would you have used instead?

On Friday, 13 December 2013 at 15:58:43 UTC, dennis luehring wrote:
> Am 13.12.2013 14:56, schrieb logicchains:
>> I didn't realise D could do that; I've updated the code to use
>> that style of variable declaration. It's interesting to be able
>> to declare two arrays at once like so:
>
> please revert - it looks terrible newbie like, no one except Rikki writes it like this
>
> it makes absolutely no sense to pseudo-scope these enums and variable declarations, they do not share anything except the type AND that is not enough for pseudo-scope

Honestly I've never written code like that. But then again I've never had 10+ constants of same type in one file before...
For me personally its easier to read as not having the type duplicated. I'd rather read it once and keep it in mind for a whole block of them. But I don't mind being unique in this way.

On Saturday, 14 December 2013 at 05:44:43 UTC, Rikki Cattermole wrote:
> Honestly I've never written code like that. But then again I've never had 10+ constants of same type in one file before...
> For me personally its easier to read as not having the type duplicated. I'd rather read it once and keep it in mind for a whole block of them. But I don't mind being unique in this way.

I realised it was possible to use untyped constants in D and removed the types, allowing me to declare all the constants in a single enum. Now it looks quite similar to the Go constant declarations.

On 13/12/13 23:02, Ali Çehreli wrote:
> Thanks for teaching me a new term. :)

Yea, my reaction was something like -- "What??!!  [one Google later]  Oh.  K&R style."

Except that strictly speaking, K&R style has functions' opening braces on a separate line and only conditionals' opening braces on the same line.

On 14/12/13 03:17, Manu wrote:
> I don't care which, I just like consistency. And it seemed to me that the
> largest body of D code as maintained by the official community should probably
> define such a standard, but clearly that boat has long sailed, so I guess it
> doesn't matter.

For quite a long time I wrote D code using essentially the same coding style I'd adopted for C/C++: K&R style braces, tabs for indent/spaces for alignment, probably one or two other things I can't recall now.  (Basically apart from the strict indentation rules, I swiped it from the Linux Kernel guidelines, on the grounds that this was probably A Good Thing:-)

Then I started contributing to Phobos and realized that I'd have to adapt an alternative style for those contributions, and I didn't like it much; and I went so far as to use different editors for my personal D work and for Phobos work.

Then when I came to the point of writing stuff of my own for immediate public distribution I realized that I was being silly and that if I wanted to write stuff that was usable for everyone, I might as well just use the standard D style guide for everything.

And now I do, and to be honest I can't work out why I was so keen to hang on to my previous style (which I'd probably still use for C/C++ where it's more idiomatic).

It's just a style, and as long as it's simple and easy to follow and to implement automatically in an editor, the details don't really matter.  It just matters that we have a style and it would be a good thing if publicly-shared repositories all made use of it.

On Saturday, 14 December 2013 at 06:23:28 UTC, logicchains wrote:
> On Saturday, 14 December 2013 at 05:44:43 UTC, Rikki Cattermole wrote:
>> Honestly I've never written code like that. But then again I've never had 10+ constants of same type in one file before...
>> For me personally its easier to read as not having the type duplicated. I'd rather read it once and keep it in mind for a whole block of them. But I don't mind being unique in this way.
>
> I realised it was possible to use untyped constants in D and removed the types, allowing me to declare all the constants in a single enum. Now it looks quite similar to the Go constant declarations.

Personally for me its going a little far just having enum { with multiple types being used as a value. But hey as long as everyone can understand it, no problems!