On 4/16/17 3:50 AM, Shachar Shemesh wrote:
> https://issues.dlang.org/show_bug.cgi?id=14246

I'd raised the importance and urgency of this issue in the past. Walter is really overloaded for the time being. Any volunteer wants to look into this now? -- Andrei

On Sunday, 16 April 2017 at 14:25:22 UTC, Andrei Alexandrescu wrote:
> On 4/16/17 3:50 AM, Shachar Shemesh wrote:
>> https://issues.dlang.org/show_bug.cgi?id=14246
>
> I'd raised the importance and urgency of this issue in the past. Walter is really overloaded for the time being. Any volunteer wants to look into this now? -- Andrei

I am going to take a look.
This bug has been bugging me for a while ... it's time to take a shot at it ;)

On Sunday, 16 April 2017 at 08:44:07 UTC, Walter Bright wrote:
> When anyone mentions the Compiler Shootout for the last 10 years, Isaac always pops up and says he won't put it on his site. I wish he'd just go away.

I wish the D community would stop using the benchmarks game as an excuse.

On Sunday, 16 April 2017 at 07:11:23 UTC, Isaac Gouy wrote:
> On Sunday, 16 April 2017 at 04:19:56 UTC, Joakim wrote:
>> came out tops if I weighted time, memory, and source code size equally.  Not always highest, as Free Pascal would sometimes beat it, but D usually won.
>
> You juggled the numbers to get a result ;-)

Nope, simply weighted everything equally and saw what came out on top, strange that you call equal weights "juggling the numbers."  As I said, I'd only heard of D once before and certainly wasn't using it, so I wasn't out to get a particular result.

>> This one doesn't show any benchmarks because it says it's in your game, so you are involved.
>
> No it does not say that.
>
> It says "This directory contains the Julia version of the "The Computer Language Benchmarks Game".
>
> It provides "perf.jl" to time those Julia programs.
>
> Those Julia programs are not included in the benchmarks game.

You're right, I saw the links to the game and thought they were saying it did, guess not.

>> I'm guessing that's because he tried to update the old D benchmarking code and likely the C/C++ code has been optimized a lot more since. ...
>> I suspect D would do just as well on the other benchmarks now.
>
> What a great opportunity for someone in the D community to help publicize the language!

As I pointed out to you, there are other benchmarks already doing that.

You're free to include whatever languages you like in your game, of course, but it's strange that you're throwing out languages that were already implemented for all the benchmarks and doing well, especially since their communities would be happy to keep them up to date.

On Sun, 2017-04-16 at 16:09 +0000, Isaac Gouy via Digitalmars-d wrote:
> 
[…]
> I wish the D community would stop using the benchmarks game as an excuse.
> 

But you have a position of great power. People look at your game and if
a language isn't in it, it is assumed to be crap. You may not be making
choices with this in mind, but a lot of programmers and managers make
this inference. This is particularly the case because not all the
languages are computationally inclined.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sunday, 16 April 2017 at 07:50:43 UTC, Shachar Shemesh wrote:
> The first is that the language does not offer any RAII containers out of the box. What it does provide is the *ability* to create RAII containers. D supports RAII, but does not actually have RAII.

Semantic game. D actually has RAII.

And D does have RAII containers: https://dlang.org/phobos/std_container.html

> (And, yes, there is an open bug: https://issues.dlang.org/show_bug.cgi?id=14246)

So we can say that D has buggy RAII. Claiming that D doesn't have RAII is equally false.

On Sunday, 16 April 2017 at 17:00:25 UTC, Jack Stouffer wrote:
> Semantic game. D actually has RAII.
>
> And D does have RAII containers: https://dlang.org/phobos/std_container.html


I wouldn't really call them RAII containers if they aren't @nogc, and especially so if they aren't structs but classes. The container module needs a good rewriting, SList/DList are the most useless POS containers without some concept of iterators.

On Sunday, 16 April 2017 at 18:36:30 UTC, Jerry wrote:
> I wouldn't really call them RAII containers if they aren't @nogc

Moving the goal posts again. Even still,

void main() @nogc
{
    Array!int ai;
    ai ~= 1;
    assert(ai.front == 1);

    ai.reserve(10);
    assert(ai.capacity == 10);

    static immutable arr = [1, 2, 3];
    ai.insertBack(arr);
}

On 4/16/17 12:05 PM, Stefan Koch wrote:
> On Sunday, 16 April 2017 at 14:25:22 UTC, Andrei Alexandrescu wrote:
>> On 4/16/17 3:50 AM, Shachar Shemesh wrote:
>>> https://issues.dlang.org/show_bug.cgi?id=14246
>>
>> I'd raised the importance and urgency of this issue in the past. Walter is really overloaded for the time being. Any volunteer wants to look into this now? -- Andrei
> 
> I am going to take a look.
> This bug has been bugging me for a while ... it's time to take a shot at it ;)

Terrific, thanks! -- Andrei

On Sunday, 16 April 2017 at 22:18:51 UTC, Jack Stouffer wrote:
> On Sunday, 16 April 2017 at 18:36:30 UTC, Jerry wrote:
>> I wouldn't really call them RAII containers if they aren't @nogc
>
> Moving the goal posts again. Even still,
>
> void main() @nogc
> {
>     Array!int ai;
>     ai ~= 1;
>     assert(ai.front == 1);
>
>     ai.reserve(10);
>     assert(ai.capacity == 10);
>
>     static immutable arr = [1, 2, 3];
>     ai.insertBack(arr);
> }

Okay, only one container, and happens to be most simple basic one. The others aren't nogc and some of them are even classes. Not only that, Array wasn't @nogc until about a month ago.

No idea what you mean about goal posts. Do you mean it's not an issue worth discussing? You made a false claim, and you still you are still persisting in it as if having a single container be @nogc solves the entire issue.