Re: D2 port of Sociomantic CDGC available for early experiments
On Thu, 23 Oct 2014 15:27:50 +0100, Leandro Lucarella l...@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/
Re: D2 port of Sociomantic CDGC available for early experiments
On Tue, 21 Oct 2014 23:52:22 +0100, Leandro Lucarella l...@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/
Re: D2 port of Sociomantic CDGC available for early experiments
On Mon, 20 Oct 2014 18:19:33 +0100, Sean Kelly s...@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/
Re: D2 port of Sociomantic CDGC available for early experiments
On Fri, 17 Oct 2014 17:54:55 +0100, Leandro Lucarella l...@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/
Re: D2 port of Sociomantic CDGC available for early experiments
On Fri, 17 Oct 2014 00:01:39 +0100, Leandro Lucarella l...@llucax.com.ar
wrote:
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. Something built into the language or runtime itself.
And, better yet would be something that is more generally useful - not
limited to GC init etc.
Wouldn't it be more generally useful to have another function like
main() called init() which if present (optional) is called
before/during initialisation. It would be passed the command line
arguments. Then a program can chose to implement it, and can use it
to configure the GC in any manner it likes.
Seems like this could be generally useful in addition to solving
this issue.
It is nice, but a) a different issue, this doesn't provide
initialization time configuration.
I don't follow. You want to execute some code A before other code B
occurs. This meets that requirement - assuming init() is called at the
point you need it to be called.
Think of development vs. devops. If
devops needs to debug a problem they could potentially re-run the
application activating GC logging, or GC stomping. No need to recompile,
no need to even have access to the source code.
./application -gclog
./application -gcstomp
..code..
init(string[] args)
{
if ..
}
Not need to recompile.
Some GC options might make sense for all D applications, in that case the
compiler default init() could handle those and custom init() functions
would simply call it, and handle any extra custom options.
Other GC/allocation options might be very application specific i.e.
perhaps the application code cannot support RC for some reason, etc.
And b) where would this init() function live? You'll have to define it
always
Surely not.
, even if you don't want to customize anything, otherwise the
compiler will have to somehow figure out if one is provided or not and
if is not provided, generate a default one. Not a simple solution to
implement.
Sounds pretty trivial to me.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: D2 port of Sociomantic CDGC available for early experiments
On Thu, 16 Oct 2014 09:10:38 +0100, Dylan Knutson tcdknut...@gmail.com wrote: Wouldn't it be more generally useful to have another function like main() called init() which if present (optional) is called before/during initialisation. It would be passed the command line arguments. Then a program can chose to implement it, and can use it to configure the GC in any manner it likes. Seems like this could be generally useful in addition to solving this issue. Isn't this what module constructors are for? As for passed in parameters, I'm sure there's a cross platform way to retrieve them without bring passed them directly, ala how Rust does it. Provided module constructors occur early enough in the process I guess this would work. You would need to ensure the module constructor doing the GC configuration occurred first too I guess. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: D2 port of Sociomantic CDGC available for early experiments
On Sat, 11 Oct 2014 01:45:48 +0100, Leandro Lucarella l...@llucax.com.ar wrote: Walter Bright, el 9 de October a las 17:28 me escribiste: On 10/9/2014 7:25 AM, Dicebot wrote: At the same time I don't see what real benefit such runtime options brings to the table. This is why in my PR garbage collector is currently chosen during compilation time. Choosing at compile time is probably best. This is not (only) about picking a GC implementation, but also about GC *options/configuration*. The fact that right now to select between concurrent or not would mean using a different GC altogether is just an implementation detail. As I said, if at some point we can merge both, this wouldn't be necessary. Right now GDGC can disable the concurrent scanning, among other cool things (like enabling memory stomping, enabling logging of allocations to a file, enable logging of collections to a file, controlling the initial pools of memory when the program starts, etc.). This is very convenient to turn on/off not exactly at *runtime* but what I call *initialization time* or program startup. Because sometimes recompiling the program with different parameters is quite annoying, and as said before, for stuff that needs to be initialized *before* any actual D code is executed, sometimes is not easy to be done *inside* D code in a way that's not horrible and convoluted. 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. Wouldn't it be more generally useful to have another function like main() called init() which if present (optional) is called before/during initialisation. It would be passed the command line arguments. Then a program can chose to implement it, and can use it to configure the GC in any manner it likes. Seems like this could be generally useful in addition to solving this issue. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Tue, 27 May 2014 22:40:00 +0100, Walter Bright newshou...@digitalmars.com wrote: On 5/27/2014 2:22 PM, w0rp wrote: I'm actually a native speaker of 25 years and I didn't get it at first. Natural language communicates ideas approximately. What bugs me is when people say: I could care less. I've always assumed some sort of sentence finishing laziness on their part. As in, I could care less, but it would be pretty hard to do so or something like that. R
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Thu, 29 May 2014 20:40:10 +0100, Walter Bright newshou...@digitalmars.com wrote: On 5/29/2014 11:25 AM, Dmitry Olshansky wrote: Agreed. The simple dream of automatically decoding UTF and staying Unicode correct is a failure. Yes. Attempting to hide the fact that strings are UTF-8 is just doomed. It's like trying to pretend that floating point does not do rounding. It's far more practical to embrace what it is and deal with it. Yes, D programmers will need to understand what UTF-8 is. I don't see any way around that. And it's the right choice. 4 of the 7 billion people in the world today are in Asia and by 2100 80% of the worlds population will be in Asia and Africa. http://bigthink.com/neurobonkers/it-is-not-about-political-views-or-ideologies-it-is-blunt-facts-which-are-not-known R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
