On Fri, 17 Oct 2014 11:18:27 +0100, Leandro Lucarella <luca@llucax.com.ar> wrote:

> Regan Heath, el 17 de October a las 10:55 me escribiste:
>> >Regan Heath, el 14 de October a las 11:11 me escribiste:
>> >>>I still don't understand why wouldn't we use environment variables  
>> for
>> >>>what they've been created for, it's foolish :-)
>> >>
>> >>As mentioned this is not a very windows friendly/like solution.
>> >
>> >As mentioned you don't have to use a unique cross-platform solution,  
>> you
>> >can have different solutions for different OSs. No need to lower down  
>> to
>> >the worse solution.
>>
>> You've got it backwards.  I'm looking for a *better* solution than
>> environment variables, which are a truly horrid way to control
>> runtime behaviour IMHO.
>
> OK, then this is now a holly war. So I'll drop it here.

I think you've mistook my tone.  I am not "religious" about this.  I just think it's a bad idea for a program to alter behaviour based on a largely invisible thing (environment variable).  It's far better to have a command line switch staring you in the face.

Plus as Walter mentioned the environment variable is a bit like a shotgun, it could potentially affect every program executed from that context.

We have a product here which uses env vars for trace flags and (without having separate var for each process) you cannot turn on trace for a single process in an execution tree, instead each child inherits the parent environment and starts to trace.  And.. when some of those flags have different meanings in different processes it gets even worse.  Especially if one of those flags prints debugging to stdout, and the process is run as a child where input/output are parsed.. it just plain doesn't work.  It's a mess.

R

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

Regan Heath, el 17 de October a las 15:43 me escribiste:
> >>You've got it backwards.  I'm looking for a *better* solution than environment variables, which are a truly horrid way to control runtime behaviour IMHO.
> >
> >OK, then this is now a holly war. So I'll drop it here.
> 
> I think you've mistook my tone.  I am not "religious" about this.  I just think it's a bad idea for a program to alter behaviour based on a largely invisible thing (environment variable).  It's far better to have a command line switch staring you in the face.

But it's not the same. I don't mean to be rude, but all you (and Walter) are saying about environment is evidence of not knowing how useful they are in POSIX OSs, what's the history in those OSs and what people expect from them. All these fear about how this can obscurely affect programs is totally unfunded. That just does not happen. Not at least commonly enough to ignore all the other advantages of it.

If you keep denying it usefulness and how they are different from command-line arguments, we'll keep going in circles.

> Plus as Walter mentioned the environment variable is a bit like a shotgun, it could potentially affect every program executed from that context.
> 
> We have a product here which uses env vars for trace flags and (without having separate var for each process) you cannot turn on trace for a single process in an execution tree, instead each child inherits the parent environment and starts to trace.

So, your example is a D program, that spawns other D programs, so if you set an environment variable to affect the behaviour of the starting program, you affect also the behaviour of the child programs. This is a good example, and I can argue for environment variables for the same reason. If I want to debug this whole mess, using command-line options there is no way I can affect the whole execution tree to log useful debug information. See, you proved my point, environment variables and command-line arguments are different and thus, useful for different situations.

> And.. when some of those flags have different meanings in different processes it gets even worse.

Why would they? Don't create problems where there are any :)

> Especially if one of those flags prints
> debugging to stdout, and the process is run as a child where
> input/output are parsed.. it just plain doesn't work.  It's a mess.

If you write to stdout (without giving the option to write to a log file) then what you did is just broken. Again, there is no point in inventing theoretical situations where you can screw anything up. You can always fabricate those. Let's stay on the domain of reality :)

In all the years I've been working in Linux I never, EVER came across problems with environment variables being accidentally set. I find it very hard to believe this is a real problem. On the other hand, they saved my ass several times (LD_PRELOAD I LOVE YOU).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
Le pedí que me enseñe a usar el mouse
Pero solo quiere hablarme del Bauhaus
Le pregunté si era chorra o rockera
Me dijo "Gertrude Stein era re-tortillera"
Me hizo mucho mal la cumbiera intelectual

On 10/17/14, Leandro Lucarella via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> In all the years I've been working in Linux I never, EVER came across problems with environment variables being accidentally set. I find it very hard to believe this is a real problem. On the other hand, they saved my ass several times (LD_PRELOAD I LOVE YOU).

Slightly OT, but having to use Linux for the past 5 months and using almost exclusively Windows before that for the better part of the last ~20 years, I have to say I've become a massive fan of the OS and the way things work. 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.

Of course, all of this functionality was available on Windows as well, but what I'm saying is a switch in one's environment (pardon the pun :p) can make them realize that they may have been doing things the slow or inefficient way.

So it's not so much about OS A vs OS B, but how used you are to doing things one way. Maybe that's why there's this aversion towards using environment variables.

Anyway those were my 2 eurocents..

On Fri, 17 Oct 2014 17:54:55 +0100, Leandro Lucarella <luca@llucax.com.ar> wrote:
> Regan Heath, el 17 de October a las 15:43 me escribiste:
>> I think you've mistook my tone.  I am not "religious" about this.  I
>> just think it's a bad idea for a program to alter behaviour based on
>> a largely invisible thing (environment variable).  It's far better
>> to have a command line switch staring you in the face.
>
> But it's not the same. I don't mean to be rude, but all you (and Walter)
> are saying about environment is evidence of not knowing how useful they
> are in POSIX OSs

I am aware of how they are used as I have had to deal with them in the past. :)

> what's the history in those OSs and what people expect from them.

D is not simply for these OSs and should be as platform agnostic as possible for core functionality.

> All these fear about how this can obscurely affect programs
> is totally unfunded. That just does not happen. Not at least commonly
> enough to ignore all the other advantages of it.

Sure, but past/current env vars being used are used *privately* to a single program.  What you're suggesting here are env vars which will affect *all* D programs that see them.  If D takes over the world as we all hope it will then this will be a significantly different situation to what you are used to.

> If you keep denying it usefulness and how they are different from
> command-line arguments, we'll keep going in circles.

I am not denying they are useful.  I am denying they are *better* than a command line argument *for this specific use case*

>> Plus as Walter mentioned the environment variable is a bit like a
>> shotgun, it could potentially affect every program executed from
>> that context.
>>
>> We have a product here which uses env vars for trace flags and
>> (without having separate var for each process) you cannot turn on
>> trace for a single process in an execution tree, instead each child
>> inherits the parent environment and starts to trace.
>
> So, your example is a D program, that spawns other D programs, so if you
> set an environment variable to affect the behaviour of the starting
> program, you affect also the behaviour of the child programs.

Yes.  How do you control which of these programs is affected by your global-affects-all-D-programs-env-var?

> This is a good example, and I can argue for environment variables for the same
> reason. If I want to debug this whole mess, using command-line options
> there is no way I can affect the whole execution tree to log useful
> debug information.

Sure you can.  You can do whatever you like with an argument, including passing a debug argument to sub-processes as required.  Or, you could use custom env vars to do the same thing.

What you *do not* want is a global env var that indiscriminately affects every program that sees it, this gives you no control.

> See, you proved my point, environment variables and
> command-line arguments are different and thus, useful for different
> situations.

Sure, but the point is that a global env var that silently controls *all* D programs is a shotgun blast, and we want a needle.

>> And.. when some of those flags have different meanings in different
>> processes it gets even worse.
>
> Why would they? Don't create problems where there are any :)

Sadly it exists .. I inherited it (the source is 20+ years old).

>> Especially if one of those flags prints
>> debugging to stdout, and the process is run as a child where
>> input/output are parsed.. it just plain doesn't work.  It's a mess.
>
> If you write to stdout (without giving the option to write to a log
> file) then what you did is just broken. Again, there is no point in
> inventing theoretical situations where you can screw anything up. You
> can always fabricate those. Let's stay on the domain of reality :)

Sadly not theoretical.

R

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

On Monday, 20 October 2014 at 10:39:28 UTC, Regan Heath wrote:
>
> Sure, but past/current env vars being used are used *privately* to a single program.  What you're suggesting here are env vars which will affect *all* D programs that see them.  If D takes over the world as we all hope it will then this will be a significantly different situation to what you are used to.

I'm not advocating the approach, but you could create a "run_d"
app that simply set the relevant environment args and then
executed the specified app as a child process.  The args would be
picked up by the app without touching the system environment.
This would work on Windows as well as on *nix.

On Friday, 17 October 2014 at 08:28:23 UTC, Martin Nowak wrote:
> On Friday, 17 October 2014 at 05:38:05 UTC, thedeemon wrote:
>> Gentlemen, do I understand correctly that you're trying to find a Windows-friendly switch to something that will never see the light on Windows (because of being based on fork)?
>
> No we want general runtime configuration, not only for the forking GC.
> https://github.com/D-Programming-Language/druntime/pull/986

But doesn't that make the goal of testing the concurrent gc dependent on the problem of finding a method for cross-platform runtime configuration?

While I do understand the need, I do not see why we need to come up with a perfect solution for one thing, before we start on what we really wanted to do in the first place.

On Mon, 20 Oct 2014 18:19:33 +0100, Sean Kelly <sean@invisibleduck.org> wrote:

> On Monday, 20 October 2014 at 10:39:28 UTC, Regan Heath wrote:
>>
>> Sure, but past/current env vars being used are used *privately* to a single program.  What you're suggesting here are env vars which will affect *all* D programs that see them.  If D takes over the world as we all hope it will then this will be a significantly different situation to what you are used to.
>
> I'm not advocating the approach, but you could create a "run_d"
> app that simply set the relevant environment args and then
> executed the specified app as a child process.  The args would be
> picked up by the app without touching the system environment.
> This would work on Windows as well as on *nix.

Sure, but in this case passing an argument is both simpler and clearer (intent).

This is basically trying to shoehorn something in where it was never intended to be used, envvars by design are supposed to affect everything running in the environment and they're the wrong tool for the job if you want to target specific processes, which IMO is a requirement we have.

A specific example.  Imagine we have the equivalent of the windows CRT debug malloc feature bits, i.e. never free or track all allocations etc.  These features are very useful, but they are costly.  Turning them on for an entire process tree may be unworkable - it may be too slow or consume too much memory.  A more targeted approach is required.

There are plenty of options, but a global envvar is not one of them.

R

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

Regan Heath, el 20 de October a las 11:39 me escribiste:
> On Fri, 17 Oct 2014 17:54:55 +0100, Leandro Lucarella <luca@llucax.com.ar> wrote:
> >Regan Heath, el 17 de October a las 15:43 me escribiste:
> >>I think you've mistook my tone.  I am not "religious" about this.  I just think it's a bad idea for a program to alter behaviour based on a largely invisible thing (environment variable).  It's far better to have a command line switch staring you in the face.
> >
> >But it's not the same. I don't mean to be rude, but all you (and Walter) are saying about environment is evidence of not knowing how useful they are in POSIX OSs
> 
> I am aware of how they are used as I have had to deal with them in the past. :)

OK, then it's even more difficult to understand your concerns or arguments. :S

> >what's the history in those OSs and what people expect from them.
> 
> D is not simply for these OSs and should be as platform agnostic as possible for core functionality.

The runtime is not platform independent AT ALL. Why should you provide a platform agnostic way to configure it? I can understand it if it's free, but if you have to sacrifice something just to get a platform agnostic mechanism, for me it's not worth it at all.

> >All these fear about how this can obscurely affect programs
> >is totally unfunded. That just does not happen. Not at least commonly
> >enough to ignore all the other advantages of it.
> 
> Sure, but past/current env vars being used are used *privately* to a single program.

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.

> What you're suggesting here are env vars which will
> affect *all* D programs that see them.

Yes, *only* D programs, something much less crazy than the standard
environment variables that affect every single program (D or not D). :)

> If D takes over the world as we all hope it will then this will be a significantly different situation to what you are used to.

No, not at all, not in the posix world.

> >If you keep denying it usefulness and how they are different from command-line arguments, we'll keep going in circles.
> 
> I am not denying they are useful.  I am denying they are *better* than a command line argument *for this specific use case*

OK, fair enough, but I can't buy your arguments, because they are based on false assumptions.

> >>We have a product here which uses env vars for trace flags and (without having separate var for each process) you cannot turn on trace for a single process in an execution tree, instead each child inherits the parent environment and starts to trace.
> >
> >So, your example is a D program, that spawns other D programs, so if you set an environment variable to affect the behaviour of the starting program, you affect also the behaviour of the child programs.
> 
> Yes.  How do you control which of these programs is affected by your global-affects-all-D-programs-env-var?

By using setenv() from the spawned program, same as you would pass
--command-line-options.

> >This is a good example, and I can argue for environment variables
> >for the same
> >reason. If I want to debug this whole mess, using command-line options
> >there is no way I can affect the whole execution tree to log useful
> >debug information.
> 
> Sure you can.  You can do whatever you like with an argument, including passing a debug argument to sub-processes as required. Or, you could use custom env vars to do the same thing.

But then you have to modify the program that spawns the other processes.
In that case, if we assume you can modify that program, you can
perfectly use setenv() in the fork()ed process before doing exec().

> What you *do not* want is a global env var that indiscriminately affects every program that sees it, this gives you no control.

Why not? You can control it the same as --command-line arguments if you are assuming you control the way programs are started.

> >See, you proved my point, environment variables and
> >command-line arguments are different and thus, useful for different
> >situations.
> 
> Sure, but the point is that a global env var that silently controls *all* D programs is a shotgun blast, and we want a needle.

This is what I'm actively denying saying is a myth, you are just scaring children talking about the boogeyman. As I said before, in posix, there are already several env variable that affects each and every program, D or not D, that's dynamically linked. I have the feeling there are env variables that affects glibc too, which would affect every single C/C++/D program, even statically linked programs. I know for a fact there are plenty of libraries that are configured using env variables, so every application using those libraries will be affected by those env variables (libev/libevent or glib[1] meaning each and every gtk+ application is affected, that meaning the whole GNOME desktop environment is affected).

This is a super common mechanism. I never ever had problems with this. Did you? Did honestly you even know they existed?

[1] https://developer.gnome.org/glib/stable/glib-running.html

This is the last time I'll mention this, I'm getting tired to go over and over again about it.

> >>And.. when some of those flags have different meanings in different processes it gets even worse.
> >
> >Why would they? Don't create problems where there are any :)
> 
> Sadly it exists .. I inherited it (the source is 20+ years old).

OK, someone wrote a bad program 20+ years ago, we should ban env variables! :-)

> >>Especially if one of those flags prints
> >>debugging to stdout, and the process is run as a child where
> >>input/output are parsed.. it just plain doesn't work.  It's a mess.
> >
> >If you write to stdout (without giving the option to write to a log file) then what you did is just broken. Again, there is no point in inventing theoretical situations where you can screw anything up. You can always fabricate those. Let's stay on the domain of reality :)
> 
> Sadly not theoretical.

Anyone can write crappy software, that's besides this point. You are not forced to do it wrong. Just the bare possibility of doing something wrong is not a good reason to not do it right. This problem is fixed by just not doing it wrong.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
"CIRILO" Y "SIRACUSA" DE "SEÑORITA MAESTRA": UNO MUERTO Y OTRO PRESO
	-- Crónica TV

On Tue, 21 Oct 2014 23:52:22 +0100, Leandro Lucarella <luca@llucax.com.ar> wrote:
> The runtime is not platform independent AT ALL.
              ^ implementation

> Why should you provide a platform agnostic way to configure it?

Because it makes life easier for developers and cross platform development, not to mention documentation.  The benefits far outweigh the costs.

> I can understand it if it's free,
> but if you have to sacrifice something just to get a platform agnostic
> mechanism, for me it's not worth it at all.

Reasonable people may disagree.

>> >All these fear about how this can obscurely affect programs
>> >is totally unfunded. That just does not happen. Not at least commonly
>> >enough to ignore all the other advantages of it.
>>
>> Sure, but past/current env vars being used are used *privately* to a
>> single program.
>
> 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.  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?

Regan

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

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.