D2 port of Sociomantic CDGC available for early experiments

Tue Oct 21 15:52:22 PDT 2014

Regan Heath, el 20 de October a las 11:39 me escribiste:
> On Fri, 17 Oct 2014 17:54:55 +0100, Leandro Lucarella
> <luca at 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