On Thursday, 9 October 2014 at 18:33:25 UTC, Rainer Schuetze wrote:
> This is a gcc extension, which isn't supported under Windows by dmd. Can you add this attribute in GDC/LDC as part of a D file aswell?

http://wiki.dlang.org/LDC-specific_language_changes#LDC_global_crt_ctor_and_LDC_global_crt_dtor

David

On 2014-10-09 20:33, Rainer Schuetze wrote:

> This is a gcc extension, which isn't supported under Windows by dmd.

It seems to be possible in Visual Studio [1], but that still leaves OMF.

[1] http://stackoverflow.com/questions/1113409/attribute-constructor-equivalent-in-vc

-- 
/Jacob Carlborg

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.

On 10/9/2014 11:25 AM, Rainer Schuetze wrote:
> Martin is very much against this, one reason is that it does not work with
> druntime in a shared library.

I can understand that, but I also don't know what a reasonable use case would be for sharing a library yet using different GC's - it sounds like complexity without purpose.

On 10.10.2014 02:30, Walter Bright wrote:
> On 10/9/2014 11:25 AM, Rainer Schuetze wrote:
>> Martin is very much against this, one reason is that it does not work
>> with
>> druntime in a shared library.
>
> I can understand that, but I also don't know what a reasonable use case
> would be for sharing a library yet using different GC's - it sounds like
> complexity without purpose.

It was my impression that phobos in a shared library would soon become the default on linux, i.e. any application would use it by default. In that case, all supported GCs might actually have to be included in the shared library.

The options to embed into the application are used to get the best performance for the specific task using any GC available through the shared library. That could include enabling/disabling preciseness, tweaking initial pool sizes and increase strategy or disabling the final collection that even runs if the GC is disabled (and might be useful only for a very limited number of application).

On 09.10.2014 21:38, David Nadlinger wrote:
> On Thursday, 9 October 2014 at 18:33:25 UTC, Rainer Schuetze wrote:
>> This is a gcc extension, which isn't supported under Windows by dmd.
>> Can you add this attribute in GDC/LDC as part of a D file aswell?
>
> http://wiki.dlang.org/LDC-specific_language_changes#LDC_global_crt_ctor_and_LDC_global_crt_dtor
>
>
> David

Cool.

It seems GDC has this, too, as "@attribute("constructor") or similar.

On 09.10.2014 21:46, Jacob Carlborg wrote:
> On 2014-10-09 20:33, Rainer Schuetze wrote:
>
>> This is a gcc extension, which isn't supported under Windows by dmd.
>
> It seems to be possible in Visual Studio [1], but that still leaves OMF.
>
> [1]
> http://stackoverflow.com/questions/1113409/attribute-constructor-equivalent-in-vc
>
>

Interesting. That would also be possible in D with the proposed pragma(data_seg). It still relies on the C++ startup code of the runtime, but dmc also has that (even for the VC++ section AFAICT).

On 10/10/2014 12:37 AM, Rainer Schuetze wrote:
> It was my impression that phobos in a shared library would soon become the
> default on linux, i.e. any application would use it by default. In that case,
> all supported GCs might actually have to be included in the shared library.
>
> The options to embed into the application are used to get the best performance
> for the specific task using any GC available through the shared library. That
> could include enabling/disabling preciseness, tweaking initial pool sizes and
> increase strategy or disabling the final collection that even runs if the GC is
> disabled (and might be useful only for a very limited number of application).

If there were multiple GCs, I suspect that having each GC in its own shared library would be a better option than lumping them all in one.

But currently (!) I think the use for switching GCs between the concurrent and non-concurrent one is simply for evaluation purposes.

On Friday, 10 October 2014 at 07:37:49 UTC, Rainer Schuetze wrote:
> It was my impression that phobos in a shared library would soon become the default on linux, i.e. any application would use it by default. In that case, all supported GCs might actually have to be included in the shared library.

This doesn't mean that all GC implementations need to be put into single Phobos distrubution. I doubt it is a good idea.

Better approach would be to separate libdruntime.so from libphobos.so again and provide separate libdruntime.so distributions with different GC implementations (with one being the default)

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

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
For long you live and high you fly
But only if you ride the tide
And balanced on the biggest wave
You race towards an early grave.