On 12.10.2014 05:41, Walter Bright wrote:
> On 10/11/2014 4:23 PM, Leandro Lucarella wrote:
>> It basically defines a bunch of environment variables and run the
>> binary. This is a super common practice in posix systems. We are not
>> inventing anything here. I don't know how windows or other OSs deal with
>> defining environment variables in a script.
>>
>> Very basic facilities are always configured this way, for example try
>> man 3 mallopt to see how can you change options in the malloc
>> implementation using environment variables...
>>
>
> I don't deny it is common practice on Linux, but defining a bunch of
> environment variables and then running the app, i.e. using the ev's as
> command line switches, seems pointless. Just use command line switches.
>
> Anyhow, environment variables are a common source of problems on
> Windows, which is why dmd, for example, uses dmd.conf instead.

C# programs also use app.exe.config files alongside the executable to setup the application. Maybe we could do something similar.

I just found this in msbuild/14.0/bin/csc.exe.config:

<configuration>
  <runtime>
    <gcServer enabled="true" />
    <gcConcurrent enabled="false"/>
  </runtime>
</configuration>

On 2014-10-12 10:30, Rainer Schuetze wrote:

> C# programs also use app.exe.config files alongside the executable to
> setup the application. Maybe we could do something similar.
>
> I just found this in msbuild/14.0/bin/csc.exe.config:
>
> <configuration>
>    <runtime>
>      <gcServer enabled="true" />
>      <gcConcurrent enabled="false"/>
>    </runtime>
> </configuration>
>

Eclipse uses a similar approach. It has an INI file with command line arguments. Mine as 18 arguments passed to the application.

-- 
/Jacob Carlborg

Walter Bright, el 11 de October a las 16:39 me escribiste:
> On 10/11/2014 3:59 PM, Leandro Lucarella wrote:
> >You can use different mechanisms in different OSs. There is no need to force a runtime to be OS-independent. If that were the case, then we should close the concurrent GC pull request now.
> 
> I still don't see why it can't use a special argument to the C main() function.

You can, but as someone said, sometimes you don't have control over how the program is started or there is no main. Is not the most general mechanism.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
Hey you, out there on your own
Sitting naked by the phone
Would you touch me?

Walter Bright, el 11 de October a las 20:41 me escribiste:
> On 10/11/2014 4:23 PM, Leandro Lucarella wrote:
> >It basically defines a bunch of environment variables and run the binary. This is a super common practice in posix systems. We are not inventing anything here. I don't know how windows or other OSs deal with defining environment variables in a script.
> >
> >Very basic facilities are always configured this way, for example try man 3 mallopt to see how can you change options in the malloc implementation using environment variables...
> 
> I don't deny it is common practice on Linux, but defining a bunch of environment variables and then running the app, i.e. using the ev's as command line switches, seems pointless. Just use command line switches.

Besides the extra flexibility, as mentioned many times, historically command-line parsing is supposed to be owned by the user's code. Libraries and runtimes are configured via environment variables. So, is more flexible and is what a Linux user would expect.

> Anyhow, environment variables are a common source of problems on Windows, which is why dmd, for example, uses dmd.conf instead.

Fair enough, then maybe we should support them only on posix systems.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
¿Cómo estais? ¿Cómo os senteis hoy 29 del membre de 1961 día en que
conmemoreramos la nonésima setima nebulización del martir Peperino
Pómoro junto al Rolo Puente en la ciudad de Jadad?
	-- Peperino Pómoro

Rainer Schuetze, el 12 de October a las 10:30 me escribiste:
> On 12.10.2014 05:41, Walter Bright wrote:
> >On 10/11/2014 4:23 PM, Leandro Lucarella wrote:
> >>It basically defines a bunch of environment variables and run the binary. This is a super common practice in posix systems. We are not inventing anything here. I don't know how windows or other OSs deal with defining environment variables in a script.
> >>
> >>Very basic facilities are always configured this way, for example try man 3 mallopt to see how can you change options in the malloc implementation using environment variables...
> >>
> >
> >I don't deny it is common practice on Linux, but defining a bunch of environment variables and then running the app, i.e. using the ev's as command line switches, seems pointless. Just use command line switches.
> >
> >Anyhow, environment variables are a common source of problems on Windows, which is why dmd, for example, uses dmd.conf instead.
> 
> C# programs also use app.exe.config files alongside the executable to setup the application. Maybe we could do something similar.
> 
> I just found this in msbuild/14.0/bin/csc.exe.config:
> 
> <configuration>
>   <runtime>
>     <gcServer enabled="true" />
>     <gcConcurrent enabled="false"/>
>   </runtime>
> </configuration>

Windows only please! :-)

Also, completely unflexible, so to run 2 instances of the same program with different configuration you have to run one, modify the config file and then run the seconds?

OUCH.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
De tan fina la condesa, por no cagarse, reza.
	-- Ricardo Vaporeso

On 10/12/14, Leandro Lucarella via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> Also, completely unflexible, so to run 2 instances of the same program with different configuration you have to run one, modify the config file and then run the seconds?

Perhaps there would be a --gc-config=file.conf you could use.

But yeah, ultimately it seems to me we're just reinventing what envars are all about..

On Sat, 11 Oct 2014 01:45:48 +0100, Leandro Lucarella <luca@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/

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

On Thu, 16 Oct 2014 08:10:38 +0000
Dylan Knutson 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.

On Thursday, 16 October 2014 at 10:56:49 UTC, ketmar via Digitalmars-d-announce wrote:
> On Thu, 16 Oct 2014 08:10:38 +0000
> Dylan Knutson 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?