D2 port of Sociomantic CDGC available for early experiments

Regan Heath via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Fri Oct 17 02:55:01 PDT 2014


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


More information about the Digitalmars-d-announce mailing list