On Monday, 9 November 2015 at 12:58:39 UTC, Dragos Carp wrote:
> On Monday, 9 November 2015 at 12:28:09 UTC, FreeSlave wrote:
>>
>> I tried to install rpm-package on Fedora 20 with rpm -i, but it gives me
>>
>> error: Failed dependencies:
>> 	glibc-devel(x86-32) is needed by dmd-2.069.0-0.x86_64
>> 	libcurl(x86-32) is needed by dmd-2.069.0-0.x86_64
>>
>> Why do package depends on 32-bit libraries? Was it always like that? I never installed dmd on Fedora before.
>
> Yes, it was always like that.
> To be able to generate 32-bit binaries, and dmd-64 can do that, these 32-bit packages are required.

More common practice is to declare such dependencies as optional though.

On Monday, 9 November 2015 at 10:39:21 UTC, Thomas Brix Larsen wrote:
> Opt-in stats from Arch:
>
> https://www.archlinux.de/?page=PackageStatistics
>
> go     19.45%
> rust    5.92%
> gcc-go  5.61%
> dmd     2.56%
> ldc     1.72%
> gdc     1.60%

This matches my personal understanding of current "market" share for those.

On 11/09/2015 07:08 PM, Dicebot wrote:
> More common practice is to declare such dependencies as optional though.

I made a ticket https://issues.dlang.org/show_bug.cgi?id=15308.
Simply changing
https://github.com/D-Programming-Language/installer/blob/41fb25ce5e5ff2c14728f490ee4579ac49bb989a/linux/dmd_rpm.sh#L266
doesn't work b/c the rpmtool from debian used to build the rpm packages
doesn't support Recommends.

On Monday, 9 November 2015 at 21:38:13 UTC, Martin Nowak wrote:
> On 11/09/2015 07:08 PM, Dicebot wrote:
>> More common practice is to declare such dependencies as optional though.
>
> I made a ticket https://issues.dlang.org/show_bug.cgi?id=15308.
> Simply changing
> https://github.com/D-Programming-Language/installer/blob/41fb25ce5e5ff2c14728f490ee4579ac49bb989a/linux/dmd_rpm.sh#L266
> doesn't work b/c the rpmtool from debian used to build the rpm packages
> doesn't support Recommends.

Sorry, I don't know a single thing about RPM world thus can't really help meaningfully :(

On Wednesday, 4 November 2015 at 01:50:38 UTC, Martin Nowak wrote:
> Glad to announce D 2.069.0.
>
> http://dlang.org/download.html http://downloads.dlang.org/releases/2.x/2.069.0/
>
> This is the first release with a self-hosted dmd compiler and comes with even more rangified phobos functions, std.experimental.allocator, and many other improvements.
>
> See the changelog for more details. http://dlang.org/changelog/2.069.0.html
>
> -Martin

I'd like to put dlang people attention this:

http://forum.dlang.org/post/bxmpvrttbhfuddsymrnk@forum.dlang.org

It looks like there's been a problem when you compiled phobos because the new allocators miss !

On Thursday, 5 November 2015 at 01:08:42 UTC, Martin Nowak wrote:
> On Wednesday, 4 November 2015 at 17:52:23 UTC, Dmitry Olshansky wrote:
>> If host machine is x64 bit windows try setting large address aware bit on the executable (there are tools to do that IRC), would allow it to eat up to ~4 gigs.
>
> We're already doing that since quite a while.
> https://github.com/D-Programming-Language/dmd/commit/172b55d22bd4a144d889c3fa8d9279d8e0a0ce1c

Martin, it seems this is not working.
I just had to use editbin manually on my laptop, again.

On Wednesday, 4 November 2015 at 15:25:04 UTC, Márcio Martins wrote:
> On Wednesday, 4 November 2015 at 01:50:38 UTC, Martin Nowak wrote:
>> Glad to announce D 2.069.0.
>>
>> http://dlang.org/download.html http://downloads.dlang.org/releases/2.x/2.069.0/
>>
>> This is the first release with a self-hosted dmd compiler and comes with even more rangified phobos functions, std.experimental.allocator, and many other improvements.
>>
>> See the changelog for more details. http://dlang.org/changelog/2.069.0.html
>>
>> -Martin
>
> Seems like memory usage went up by a significant amount, as I can no longer compile our project on my Windows machine.
>
> DMD 2.068.2 uses up to 1100MB of memory during our build and succeeds
> DMD 2.069 used up to 1600MB of memory before crashing with "Error: out of memory"
>
> Are there any plans to release a dmd64.exe?


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.

So, at a first glance it looks like a deeper problem that just a "higher memory consumption" issue, to me. I'm a bit frustrated, this was working so well so far...


    auto r=ctRegex!(
        `\s*(?:`
        ~   `(?P<comment>#.*)|`
        ~   `(?:@prefix\s+(?P<prefixDecl>\pL+):\s+<(?P<iri>[^<>\s]+)>\s*\.\s*)|`
        ~   `(?:(_|\pL+):((?:\pL|[\.\-_0-9])*(?:\pL|\d))\s+(\pL+):((?:\pL|[\.\-_0-9])*(?:\pL|\d))\s+`
        ~     `(?:(?:(_|\pL+):((?:\pL|[\.\-_0-9])*(?:\pL|\d)))|`
        ~     `(?:(?:(?:"{3}(?P<literal>.*)"{3})|(?:"(?P<literal>.*)"))`
        ~           `(?:`
        ~               `(?:@(?P<langTag>[A-Za-z]+(?:\-[A-Za-z0-9]+)*))|`
        ~               `(?:\^\^(?P<typeTag1>\pL+):(?P<typeTag2>\w+))`
        ~           `)?`
        ~       `)`
        ~       `)\s*`
        ~   `\.\s*)`
        ~`)`
        );

Thank you for any help beyond splitting down the regex above (any magic memory-oriented option somewhere?) ...

Jean-Yves

PS I would like to take the opportunity to thank all contributors for their great work on D...

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?

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

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

I guess the issue is that the Windows DMD binary is 32-bit and supports addressing only 2GB (or 4GB if it's Large Address Space aware), whereas on other OSs it's 64-bit by default and doesn't have this limitation.

Maybe if you need to keep using Windows your best option is to build a 64-bit DMD yourself. I think the easiest way to do this on Windows is to use Digger: https://github.com/cybershadow/Digger