On Tuesday, 8 December 2015 at 08:39:26 UTC, Jean-Yves Vion-Dury wrote:
> On Monday, 7 December 2015 at 17:32:05 UTC, Márcio Martins wrote:
>> On Monday, 7 December 2015 at 17:06:48 UTC, Jean-Yves Vion-Dury wrote:
>>> On Wednesday, 4 November 2015 at 15:25:04 UTC, Márcio Martins wrote:
>>>> [...]
>>>
>>>
>>> FYI, I just installed the 2.069 version, and now I'm unable to compile some modules, getting the same "Error: out of memory". I isolated a tiny one raising the issue, and its all about a moderately complex ctRegex expression (see below) that seems to brake the compiler. Other modules also raise the problem, but they are bigger in term of code lines.
>>>
>>> [...]
>>
>> Windows?
>
> Yes indeed, Windows... is it a problem (the previous version was fine with my environment)?

You will need to add the add the LARGEADDRESSAWARE flag to your executable manually. It is supposed to be done automatically, but it is not working currently, so you will have to do it manually... It indeed stopped working since 2.069.0. Unfortunately, it is a royal pain in the anus, because you need to download the WDK. To save you some pain, if you have Windows 10, it's WDK doesn't install property, so you best install WDK 8.1 which works smooth. Perhaps there are some other tools that do it, but I am always reluctant to download these sort of stuff from untrusted sources.

On Tuesday, 8 December 2015 at 13:14:58 UTC, Márcio Martins wrote:
> On Tuesday, 8 December 2015 at 08:39:26 UTC, Jean-Yves Vion-Dury wrote:
>> On Monday, 7 December 2015 at 17:32:05 UTC, Márcio Martins wrote:
>>> On Monday, 7 December 2015 at 17:06:48 UTC, Jean-Yves Vion-Dury wrote:
>>>> On Wednesday, 4 November 2015 at 15:25:04 UTC, Márcio Martins wrote:
>>>>> [...]
>>>>
>>>>
>>>> FYI, I just installed the 2.069 version, and now I'm unable to compile some modules, getting the same "Error: out of memory". I isolated a tiny one raising the issue, and its all about a moderately complex ctRegex expression (see below) that seems to brake the compiler. Other modules also raise the problem, but they are bigger in term of code lines.
>>>>
>>>> [...]
>>>
>>> Windows?
>>
>> Yes indeed, Windows... is it a problem (the previous version was fine with my environment)?
>
> You will need to add the add the LARGEADDRESSAWARE flag to your executable manually. It is supposed to be done automatically, but it is not working currently, so you will have to do it manually... It indeed stopped working since 2.069.0. Unfortunately, it is a royal pain in the anus, because you need to download the WDK. To save you some pain, if you have Windows 10, it's WDK doesn't install property, so you best install WDK 8.1 which works smooth. Perhaps there are some other tools that do it, but I am always reluctant to download these sort of stuff from untrusted sources.

That's fucking ridiculous.

I'm sorry, but strong word are warranted on that one. Memory consumption have been an issue for a while now. Never freeing and assuming everything will be already to win few ms out of a build is the most ridiculous choice dmd has done.

Especially on a 32bits build.

Will this problem be taken seriously at some point ?

On Tue, 08 Dec 2015 22:07:15 +0000, deadalnix wrote:

> That's fucking ridiculous.
> 
> I'm sorry, but strong word are warranted on that one. Memory consumption have been an issue for a while now. Never freeing and assuming everything will be already to win few ms out of a build is the most ridiculous choice dmd has done.
> 
> Especially on a 32bits build.
> 
> Will this problem be taken seriously at some point ?

At the time of the C++ to D cutover, DMD did some GC-unsafe things. In the interests of expediency, since the compiler isn't a long-running process, they chose to disable the GC in the interim.

While at least some of these GC-unsafe behaviors have been excised, there is lingering concern that some might remain, so nobody has re-enabled the GC. This has been somewhat on the backburner; Windows has typically been of secondary concern to D devs, and Linux has 64-bit builds, so address space exhaustion hasn't been as problematic there.

Anyway, this is something that's intended to be fixed, and regular 64-bit Windows builds are something that should happen. It just requires the dev team to have better access to Windows.