On Thu, 16 Oct 2014 09:10:38 +0100, Dylan Knutson <tcdknutson@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/

On Thu, 16 Oct 2014 13:54:25 +0000
Sean Kelly via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> >> I'm sure there's a cross platform way to retrieve them without bring passed them directly
> > there isn't.
> Runtime.args?

it's good, but it isn't modifiable. so programmer must manually ignore gc-related args.

yet yes, i was wrong. there is a way to acces CLI args. but there is no documented way to modify 'em.

On Thu, Oct 16, 2014 at 22:12:05 +0300, ketmar via Digitalmars-d-announce wrote:
> it's good, but it isn't modifiable. so programmer must manually ignore gc-related args.

There's what Haskell (or at least GHC) does:

    ./my-haskell-program +RTS --runtime-arg1 --runtime-arg2 -RTS --program-arg1

The program doesn't see anything between +RTS and -RTS arguments.

--Ben

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.

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

And b) where would this init() function live? You'll have to define it always, 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.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
Refalar: acto de mover el peso de la masa hacia un lugar equivocado pero
concreto. Todo refalo es, por cierto, una sucesión de pequeñísimos
movimientos a los que un centímetro es la proporción aumentada de miles
de porciones de espacio, que, al estar el piso mojado, refala.
	-- Ricardo Vaporeso

Dylan Knutson, el 16 de October a las 08:10 me escribiste:
> >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?

No, this needs to be configured WAY before any module constructor even runs...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
Are you such a dreamer?
To put the world to rights?
I'll stay home forever
Where two & two always
makes up five

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

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

On Fri, 17 Oct 2014 00:01:39 +0100, Leandro Lucarella <luca@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/

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ó

Marginally related: Page fault handling in user space.
http://lwn.net/Articles/615086/

Maybe this can be used as an alternative to forking.