On Friday, 17 October 2014 at 17:53:18 UTC, Andrej Mitrovic via Digitalmars-d-announce wrote:
> I've come to even hate anything GUI (except maybe the
> editor), I'd hate to even think about browsing the file system with a
> mouse anymore.

Yes, you can: Windows Explorer does support keyboard input :)

On Thu, 23 Oct 2014 07:12:25 +0000
Kagamin via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 17 October 2014 at 17:53:18 UTC, Andrej Mitrovic via Digitalmars-d-announce wrote:
> > I've come to even hate anything GUI (except maybe the
> > editor), I'd hate to even think about browsing the file system
> > with a
> > mouse anymore.
> 
> Yes, you can: Windows Explorer does support keyboard input :)
at least it supports most useful shortcut: alt+f4.

On Thursday, 23 October 2014 at 07:09:04 UTC, Kagamin wrote:
> On Tuesday, 7 October 2014 at 20:06:43 UTC, Walter Bright wrote:
>> On 10/6/2014 9:51 AM, Dicebot wrote:
>>> https://github.com/D-Programming-Language/druntime/pull/985
>>
>> Thank you. This is great progress!
>>
>> I understand the caveats, but can this be put into a shape where it can be pulled despite being a work in progress? I.e. have the code be disabled by default? That will help encourage the community to help out with the gaps.
>
> BTW, why not dub package? GC is pluggable, so can be shipped as a 3rd-party library.

Currently druntime is packaged as part of Phobos library binary so I don't see easy way to do it. It could be possible to do the replacement at the startup using GC Proxy instrastructure but CDGC does not currently support it (though it is not complicated to do).

On Thursday, 23 October 2014 at 08:46:46 UTC, Dicebot wrote:
> Currently druntime is packaged as part of Phobos library binary so I don't see easy way to do it. It could be possible to do the replacement at the startup using GC Proxy instrastructure but CDGC does not currently support it (though it is not complicated to do).

The idea is that you specify CDGC dub package a dependency for your application and dub links your application with it, so you end up with CDGC in your application.

On Thursday, 23 October 2014 at 09:53:44 UTC, Kagamin wrote:
> On Thursday, 23 October 2014 at 08:46:46 UTC, Dicebot wrote:
>> Currently druntime is packaged as part of Phobos library binary so I don't see easy way to do it. It could be possible to do the replacement at the startup using GC Proxy instrastructure but CDGC does not currently support it (though it is not complicated to do).
>
> The idea is that you specify CDGC dub package a dependency for your application and dub links your application with it, so you end up with CDGC in your application.

Uh, what will it link to? extern(C) function like gc_malloc? druntime links to those statically itself so you will get application that links to different GC than druntime itself. Or am I misunderstanding what you propose?

On Thursday, 23 October 2014 at 09:57:38 UTC, Dicebot wrote:
> Uh, what will it link to? extern(C) function like gc_malloc?
> druntime links to those statically itself so you will get application that links to different GC than druntime itself.

The reason is CDGC provides symbols like gc_malloc and after that the linker has no reason to pull default GC from the library: it doesn't pull what's not necessary.

On Thursday, 23 October 2014 at 11:03:35 UTC, Kagamin wrote:
> On Thursday, 23 October 2014 at 09:57:38 UTC, Dicebot wrote:
>> Uh, what will it link to? extern(C) function like gc_malloc?
>> druntime links to those statically itself so you will get application that links to different GC than druntime itself.
>
> The reason is CDGC provides symbols like gc_malloc and after that the linker has no reason to pull default GC from the library: it doesn't pull what's not necessary.

It will clash at best, or just ignore cdgc, as objects are considered as a whole, in link order.

Now, if druntime defines gc_alloc, it won't link. You have to extract all conflicting symbols out of druntime.

However, one could provide a full druntime patched with CDGC as a dub module, and that might work, I suppose.

On Thursday, 23 October 2014 at 13:13:06 UTC, Mathias LANG wrote:
> It will clash at best, or just ignore cdgc, as objects are considered as a whole, in link order.

At best, they won't clash :)
If the default GC is not pulled by the linker, why should they clash?

> Now, if druntime defines gc_alloc, it won't link. You have to extract all conflicting symbols out of druntime.

Do you consider possibility of breaking changes as a blocker for feasibility of 3rd-party libraries?

Regan Heath, el 22 de October a las 10:41 me escribiste:
> >NO, this is completely false, and why I think you are not entirely familiar with env vars in posix. LD_PRELOAD and LD_LIBRARY_PATH affects ALL, EACH and EVERY program for example. D or not D. Every single dynamically linked program.
> 
> True.  And the reason these behave this way is because we *always* want them to - the same is NOT true of the proposed vars for D.

No, not at all, you very rarely want to change LD_PRELOAD and LD_LIBRARY_PATH globaly.

> Which is my point.
> 
> >This is a super common mechanism. I never ever had problems with this. Did you? Did honestly you even know they existed?
> 
> Yes.  But this is beside the point, which I hope I have clarified now?

No.

My conclusion is we don't agree mainly on this:

I think there are cases where you want runtime configuration to propagate or be set more or less globally. You think no one will ever want some runtime option to propagate.

The rest of the argument is based on that difference.

Also, I don't have much of a problem with having command-line options to configure the runtime too, although I think in linux/unix is much less natural. Runtime configuration will be most of the time some to be done either by the developer (in which case it would be nicer to have a programatic way to configure it), or on a system level, by a system administrator / devops (in which case for me environment variables are superior for me). Usually runtime options will be completely meaningless for a regular user. Also, will you document them when you use --help? Will you omit them?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
De tan fina la condesa, por no cagarse, reza.
	-- Ricardo Vaporeso

On Thursday, 23 October 2014 at 14:02:33 UTC, Kagamin wrote:
> On Thursday, 23 October 2014 at 13:13:06 UTC, Mathias LANG wrote:
>> It will clash at best, or just ignore cdgc, as objects are considered as a whole, in link order.
>
> At best, they won't clash :)
> If the default GC is not pulled by the linker, why should they clash?

We could experiment with separately linking the GC.  It wouldn't be hard to do, though the link line might be a bit weird, since core, rt, and gc are all interdependent in terms of link dependencies.