Re: D on TV - FLOSS Weekly 311
On 10/08/2014 10:41 PM, Walter Bright wrote: On 10/8/2014 6:25 PM, John wrote: I wish you had some lighting on you. You are hardly visible! It's to hide the scars where my head was sewed back on. Getting the brain out was the easy part. The hard part was getting the brain out! - Hubert Farnsworth
Re: D2 port of Sociomantic CDGC available for early experiments
On 08/10/14 22:47, Rainer Schuetze wrote: C main is no longer under user control, because it is auto-generated with D main. I never liked that change, we've just discovered another reason. All platforms have API's to access the command line arguments passed to main. On OS X that would be _NSGetArgv and _NSGetArgc. -- /Jacob Carlborg
Re: D2 port of Sociomantic CDGC available for early experiments
On 09.10.2014 08:29, Jacob Carlborg wrote: On 08/10/14 22:47, Rainer Schuetze wrote: C main is no longer under user control, because it is auto-generated with D main. I never liked that change, we've just discovered another reason. All platforms have API's to access the command line arguments passed to main. On OS X that would be _NSGetArgv and _NSGetArgc. Yes, but the problem is not to access command line arguments, but to run code before the GC initialization i.e. before _d_run_main is executed. If we can assume a C++ backend, using static initialization of a C++ global could work: static bool initGC = configureGC(); because the C++ runtime runs configureGC before calling C main. I'd rather like to see a solution using D, though.
Re: D2 port of Sociomantic CDGC available for early experiments
On 10/8/2014 11:43 PM, Rainer Schuetze wrote: Yes, but the problem is not to access command line arguments, but to run code before the GC initialization i.e. before _d_run_main is executed. If we can assume a C++ backend, using static initialization of a C++ global could work: static bool initGC = configureGC(); because the C++ runtime runs configureGC before calling C main. I'd rather like to see a solution using D, though. Define a global variable in druntime in its own module: __gshared int druntime_flags = 0; Then, in your app, override it: __gshared int druntime_flags = values...;
Re: D2 port of Sociomantic CDGC available for early experiments
On 09/10/14 08:43, Rainer Schuetze wrote: Yes, but the problem is not to access command line arguments, but to run code before the GC initialization i.e. before _d_run_main is executed. If we can assume a C++ backend, using static initialization of a C++ global could work: static bool initGC = configureGC(); because the C++ runtime runs configureGC before calling C main. I'd rather like to see a solution using D, though. It's enough with a C function with __attribute__((constructor)). This will run before C main. -- /Jacob Carlborg
Re: D2 port of Sociomantic CDGC available for early experiments
On Wednesday, 8 October 2014 at 17:39:46 UTC, Walter Bright wrote: On 10/8/2014 12:43 AM, Leandro Lucarella wrote: I think this is an unjustified fear, there are already many environment variables that can affect your program. That's why they are called... environment variables :) Being on the front lines of tech support for 30 years, it is not an unjustified fear nor a hypothetical problem. What you could do is propose a secret switch to all dmd generated programs that the druntime switch checks before main() gets control, such as: app --druntimeSet=usexxx ...the regular app args ... Back when Druntime was called Ares, it was possible to choose the GC at link time. Do we really need to defer the decision to run time? If so, switching GCs after the app has started should work in most cases, though I'm not sure offhand if memory allocated by the prior GC will be scanned through for references within the new GC.
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 9 October 2014 at 14:20:07 UTC, Sean Kelly wrote: Back when Druntime was called Ares, it was possible to choose the GC at link time. Do we really need to defer the decision to run time? If so, switching GCs after the app has started should work in most cases, though I'm not sure offhand if memory allocated by the prior GC will be scanned through for references within the new GC. This also forces GC implementations to aware of each other. Not normally an issue but GC traditionally includes many extern(C) functions with common names which will need to be always implemented so that all GC implementations are supported. 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.
Re: D2 port of Sociomantic CDGC available for early experiments
On 09.10.2014 10:18, Walter Bright wrote: On 10/8/2014 11:43 PM, Rainer Schuetze wrote: Yes, but the problem is not to access command line arguments, but to run code before the GC initialization i.e. before _d_run_main is executed. If we can assume a C++ backend, using static initialization of a C++ global could work: static bool initGC = configureGC(); because the C++ runtime runs configureGC before calling C main. I'd rather like to see a solution using D, though. Define a global variable in druntime in its own module: __gshared int druntime_flags = 0; Then, in your app, override it: __gshared int druntime_flags = values...; That's similar to my approach to replace gc.config by a different module with the same module name when compiling the executable: dmd main.d my_gc_config.d where my_gc_config.d contains module gc.config; and thus replaces the module in the library. Martin is very much against this, one reason is that it does not work with druntime in a shared library.
Re: D2 port of Sociomantic CDGC available for early experiments
On 09.10.2014 15:31, Jacob Carlborg wrote: On 09/10/14 08:43, Rainer Schuetze wrote: Yes, but the problem is not to access command line arguments, but to run code before the GC initialization i.e. before _d_run_main is executed. If we can assume a C++ backend, using static initialization of a C++ global could work: static bool initGC = configureGC(); because the C++ runtime runs configureGC before calling C main. I'd rather like to see a solution using D, though. It's enough with a C function with __attribute__((constructor)). This will run before C main. 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? I recently made some experiments with pragma(data_seg,SEGMENT_NAME) or pragma(code_seg,SEGMENT_NAME) that could also be used to move something into the initializer section of the runtime. For COFF it kind of works, but unfortunately there is no way to tell OMF to put a COMDAT (needed for templates) into a specific segment.
Re: D2 port of Sociomantic CDGC available for early experiments
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
Re: D2 port of Sociomantic CDGC available for early experiments
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
Re: D2 port of Sociomantic CDGC available for early experiments
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.
Re: D2 port of Sociomantic CDGC available for early experiments
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.
