Re: D2 port of Sociomantic CDGC available for early experiments
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
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: SDC-32bit
New backend why ?
Re: D2 port of Sociomantic CDGC available for early experiments
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. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Mi infancia fue en un loft, bien al costado del río Cazabamos correcaminos y lo asábamos en el fogón Después? Después me vine grande y la ciudad me deslumbró Jugando al tejo en Lavalle me hice amigo del bongó
Re: D2 port of Sociomantic CDGC available for early experiments
Marginally related: Page fault handling in user space. http://lwn.net/Articles/615086/ Maybe this can be used as an alternative to forking.
Re: Mono-D v2.5 - dub buildTypes
On Thursday, 16 October 2014 at 23:32:22 UTC, Alexander Bothe wrote: Hi everyone, just gave the second drop down box in Xamarin Studio a use: Selection of build types for dub projects. Furthermore, please don't rage silently somewhere - tell me about issues with Mono-D on github or in #d.mono-d on freenode! http://wiki.dlang.org/Mono-D https://github.com/aBothe/Mono-D/issues Cheers thanks to everyone, Alex Sweet
Re: CUDA bindings
On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote: More APIs could be implemented if the interest happens to be non-null. Interest non-null, this is awesome.
Re: Mono-D v2.5 - dub buildTypes
On Thursday, 16 October 2014 at 23:32:22 UTC, Alexander Bothe wrote: Cheers thanks to everyone, Alex What a hardwork are you doing, Alex! Kudos!
Re: CUDA bindings
On 10/17/14, 7:58 AM, Tofu Ninja wrote: On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote: More APIs could be implemented if the interest happens to be non-null. Interest non-null, this is awesome. Let it ride! http://www.reddit.com/r/programming/comments/2jiv21/derelictcuda_dynamic_bindings_to_the_cuda_library/ https://twitter.com/D_Programming/status/523135615521415171 Andrei
Re: D2 port of Sociomantic CDGC available for early experiments
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
Re: D2 port of Sociomantic CDGC available for early experiments
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..
Re: SDC-32bit
On Friday, 17 October 2014 at 10:39:15 UTC, Temtaime wrote: New backend why ? Because I want to code a backend. I want output C or maybe even Cool ... generating UML via a backend would also be nice.
Endovena: a dependency injection framework.
Hi all, I'd like to announce the initial version of endovena, a dependency injection framework. It's based on dejector, a great work by Jakub Stasiak, with some new features borrowed from dryioc (C# IoC) I would be glad to see any feedback, Thank you. * [endovena] https://github.com/o3o/endovena Boost License 1.0 * [dejector](https://github.com/jstasiak/dejector) * [dryioc](https://bitbucket.org/dadhi/dryioc)
