On Wednesday, 8 October 2014 at 00:18:16 UTC, Walter Bright wrote:
> Sort of like:
>
>   user: "need to fix this on the website"
>   n.g.: "thanks! fixed now!"
>   user: "no it isn't"
>   n.g.: "looks good to me"
>   [lots of fruitless back and forth]
>   n.g.: "did you refresh your browser's cache?"
>   user: "oops, sorry!"

OT: I know this is just an example to illustrate a point, but I think this particular story is about the web developer not understanding HTTP caching, or not being aware that their caching headers may cause the fix to not propagate to users indefinitely. :)

On Wednesday, 8 October 2014 at 07:14:30 UTC, Paolo Invernizzi wrote:
> On Wednesday, 8 October 2014 at 06:58:36 UTC, ketmar via Digitalmars-d-announce wrote:
>> On Tue, 07 Oct 2014 17:18:18 -0700
>> Walter Bright via Digitalmars-d-announce
>> <digitalmars-d-announce@puremagic.com> wrote:
>>
>> i assume that not everyone are ready to build dmd from sources,
>
> Digger? What can be easier?

Yes, this is a perfect use case for Digger. Just scroll down the pull request list, check the GC pull's checkbox, and click "build". What could be easier?

On 10/7/2014 11:58 PM, ketmar via Digitalmars-d-announce wrote:
> maybe enable envvar-control in alphas/betas and disable in releases?


I thought you were opposed to -release builds?

On 10/8/2014 2:55 AM, Vladimir Panteleev wrote:
> On Wednesday, 8 October 2014 at 00:18:16 UTC, Walter Bright wrote:
>> Sort of like:
>>
>>   user: "need to fix this on the website"
>>   n.g.: "thanks! fixed now!"
>>   user: "no it isn't"
>>   n.g.: "looks good to me"
>>   [lots of fruitless back and forth]
>>   n.g.: "did you refresh your browser's cache?"
>>   user: "oops, sorry!"
>
> OT: I know this is just an example to illustrate a point, but I think this
> particular story is about the web developer not understanding HTTP caching, or
> not being aware that their caching headers may cause the fix to not propagate to
> users indefinitely. :)

There are similar recurring discussions about the path to where the D libraries are, such as "I deleted all the old versions of dmd from my system, but it is still using them!" Using environment variables is a recurring support problem, even for people who understand them.

On 10/8/2014 12:43 AM, Leandro Lucarella wrote:
> I think this is an unjustified fear, there are already many environment
> variables that can affect your program. That's why they are called...
> environment variables :)

Being on the front lines of tech support for 30 years, it is not an unjustified fear nor a hypothetical problem.

What you could do is propose a "secret" switch to all dmd generated programs that the druntime switch checks before main() gets control, such as:

    app --druntimeSet=usexxx ...the regular app args ...

On Wed, 08 Oct 2014 10:33:46 -0700
Walter Bright via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> On 10/7/2014 11:58 PM, ketmar via Digitalmars-d-announce wrote:
> > maybe enable envvar-control in alphas/betas and disable in releases?
> I thought you were opposed to -release builds?
i'm opposed to "-release" flag which turns off assertions and range checking, not to the builds which can be titled "official releases". we have official DMD releases, alphas, betas and RCs. it's logical to turn on some experimental features in alphas/betas for people to play, but turn such features off for safety reasons in RC/release.

turning off assertions and range checks decreases safety. turning off experimental features and features with very unexpected side effects increases safety. it's ok to make alphas/betas less safe. it's not ok to make RCs/releases less safe.

On Wed, 8 Oct 2014 20:47:09 +0300
ketmar via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

p.s. i believe that there shouldn't be any flags that turns off range checking. if someone wants to do it "fast", he can use pointer arithmetics (this is exactly the same as using arrays with range checks off). that's what i'm doing in my code: writing everything using arrays, which are range-checked. then profiling and rewriting bottlenecks using pointer arithmetics. and i found that i rarely ever need to go pointers, 'cause optimizing algorithms has much bigger impact on performance.

On 08.10.2014 19:39, Walter Bright wrote:
> On 10/8/2014 12:43 AM, Leandro Lucarella wrote:
>> I think this is an unjustified fear, there are already many environment
>> variables that can affect your program. That's why they are called...
>> environment variables :)
>
> Being on the front lines of tech support for 30 years, it is not an
> unjustified fear nor a hypothetical problem.
>
> What you could do is propose a "secret" switch to all dmd generated
> programs that the druntime switch checks before main() gets control,
> such as:
>
>      app --druntimeSet=usexxx ...the regular app args ...
>

We have app --DRT-gcopt=concurrent in gc.config now.

There is no perfect plan how an application can change the default options that are used without arguments, though. Doing this in main() is too late for some parameters (e.g. "precise"), because the GC will have to be setup to execute "static this" and other library initialization before reaching main.

On Wednesday, 8 October 2014 at 17:39:46 UTC, Walter Bright wrote:
> Being on the front lines of tech support for 30 years, it is not an unjustified fear nor a hypothetical problem.
>
> What you could do is propose a "secret" switch to all dmd generated programs that the druntime switch checks before main() gets control, such as:
>
>     app --druntimeSet=usexxx ...the regular app args ...

I don't think this would work (without introducing extra hacks) when druntime is used as a shared library. Plus, when writing plugins in D, there might not even be a host D application to handle the command line flags.

I'm not saying that command line arguments can't be made to work in these cases too, just that doing it will likely introduce quite a bit of extra complexity.

David

On 06.10.2014 19:29, Dicebot wrote:
> On Monday, 6 October 2014 at 17:23:55 UTC, Andrei Alexandrescu wrote:
>> On 10/6/14, 9:51 AM, Dicebot wrote:
>>> https://github.com/D-Programming-Language/druntime/pull/985
>>
>> This is awesome. I recall Don had some solid performance numbers for
>> it in his talk, do you have any in the context of D2? -- Andrei
>
> No, I didn't get to running any perf test so far. Did PR as soon as test
> suite passes and commits looked sane. Will do eventually. Any specific
> project you are interested in?
>
> I'd love to see the impact on vibe.d but it is subject to
> threading/malloc issue right now.

druntime has a small benchmark suite in druntime/benchmark. I'd be very interested to see how it performs against this. (Some files are from Leandros tests.) Just compile and run "runbench.d".

I'm benchmarking my Windows version of a concurrent GC with it. It does quite a lot of allocations, and this is causing some serious trouble because marking cannot compete with the rate of allocation, causing some tests to allocate a lot of memory, slowing down marking even more. I'm still looking for a solution...