D2 port of Sociomantic CDGC available for early experiments

[Regan Heath via Digitalmars-d-announce]

On Thu, 23 Oct 2014 15:27:50 +0100, Leandro Lucarella <luca at llucax.com.ar>  
wrote:

> 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.

Sure, but when you do change them you will want them to propagate, by  
default, which is why envvars are used for these.

The same is not true of many potential D GC/allocation/debug flags, we do  
not necessarily want them to propagate at all and in fact we may want to  
target a single exe in a process tree i.e.

parent     <- not this
   child1   <- this one
     child2 <- not this

> 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.

I agree that there are cases we might want it to propagate *from a parent  
exe downwards* or similar but this is not what I would call "more or less  
globally" it's very much less than globally.  The scope we want is going  
to be either a single exe, or that exe and some or all of it's children  
and possibly only for a single execution.

Sure, you *could* wrap a single execution in it's own session and only set  
the envvar within that session but it's far simpler just to pass a command  
line arg.  Likewise, you could set an envvar in a session and run multiple  
executions within that session, but again it's simpler just to pass an arg  
each time.

Basically, I don't see what positive benefit you get from an envvar over a  
command line switch, especially if you assume/agree that the most sensible  
default these switches is 'off' and that they should be enabled  
specifically.

I think what we disagree about here is the scope it should apply and  
whether propagation should be the default behaviour.

> You think no one will ever want some runtime option to propagate.

Nope, I never said that.

> 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.

Surely not, unix is the king of command line switches.

> 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)

Agreed.

> or on a system level, by a system
> administrator / devops (in which case for me environment variables are
> superior for me).

Disagree.  It's not something we ever want at a system level, it's  
somewhere within the range of a single session <-> single execution.

> Usually runtime options will be completely meaningless
> for a regular user. Also, will you document them when you use --help?

Or course not, just as you would not document the envvar(s).

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/