On 8/11/2015 1:41 AM, Dmitry Olshansky wrote:

> IMHO enabling D's GC in the frontend is better way to fix leaking in the
> CTFE, but there are some issues with that (it segfaults if we enable GC).
>

Actually I think it's fixed now, just disabled.

It used to have problems with lib*/scan*, but those are in D now, and most of the allocations from the glue layer are being forwarded to the GC through rmem.

If anyone wants to try it they just need to add -version=GC to the DMD build flags and insert this function in root/rmem.d's version(GC) block.


    extern (C) void* allocmemory(size_t m_size)
    {
        return GC.malloc(m_size);
    }

On Sunday, 8 November 2015 at 22:45:05 UTC, Daniel Murphy wrote:
> Actually I think it's fixed now, just disabled.
>
> It used to have problems with lib*/scan*, but those are in D now, and most of the allocations from the glue layer are being forwarded to the GC through rmem.
>
> If anyone wants to try it they just need to add -version=GC to the DMD build flags and insert this function in root/rmem.d's version(GC) block.
>
>
>     extern (C) void* allocmemory(size_t m_size)
>     {
>         return GC.malloc(m_size);
>     }

Is there any reason why this isn't currently used in the front end?

On 9/11/2015 10:25 AM, Jack Stouffer wrote:

> Is there any reason why this isn't currently used in the front end?

Lack of testing, focus on matching c-dmd performance, it used to be blocked and nobody realized it wasn't any more etc.

On 11/8/15 2:58 PM, rsw0x wrote:
> Interestingly, GDC seems *very* popular - it has a 4:1 install rate of
> gccgo and only trailing slightly behind the golang-go package(reference
> compiler?) on Ubuntu's popcon.

Link? -- Andrei

On Monday, 9 November 2015 at 02:15:17 UTC, Andrei Alexandrescu wrote:
> On 11/8/15 2:58 PM, rsw0x wrote:
>> Interestingly, GDC seems *very* popular - it has a 4:1 install rate of
>> gccgo and only trailing slightly behind the golang-go package(reference
>> compiler?) on Ubuntu's popcon.
>
> Link? -- Andrei

debian:
https://qa.debian.org/popcon-graph.php?packages=gdc%2Cgccgo%2Cgolang&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

ubuntu:
http://ubuntu-popcon.43-1.org/cgi-bin/graph.pl?name=gdc
http://ubuntu-popcon.43-1.org/cgi-bin/graph.pl?name=golang-go
http://ubuntu-popcon.43-1.org/cgi-bin/graph.pl?name=gccgo

note that dmd is not redistributed on most linux distros due to licensing issues

On Sunday, 8 November 2015 at 14:37:32 UTC, Sebastiaan Koppe wrote:
> You mean instead of mixin(grammer(`...`)) I write the output of grammer(`...`) to a file and include that into the final build?

Yes, use asModule() for that [1]. Not only does it enable using large grammars, it also saves compilation time for builds after the grammar has stabilised.

And should the grammar still be too large, it is good to know that Pegged is good at composing a parser from different sub-grammars [2]. So the difficulty is only in finding natural boundaries at which the grammar can be split, making it work should be easy.

[1] https://github.com/PhilippeSigaud/Pegged/wiki/Grammars-as-D-Modules
[2] https://github.com/PhilippeSigaud/Pegged/wiki/Grammar-Composition

On Monday, 9 November 2015 at 03:15:29 UTC, rsw0x wrote:
> On Monday, 9 November 2015 at 02:15:17 UTC, Andrei Alexandrescu wrote:
>> On 11/8/15 2:58 PM, rsw0x wrote:
>>> Interestingly, GDC seems *very* popular - it has a 4:1 install rate of
>>> gccgo and only trailing slightly behind the golang-go package(reference
>>> compiler?) on Ubuntu's popcon.
>>
>> Link? -- Andrei
>
> debian:
> https://qa.debian.org/popcon-graph.php?packages=gdc%2Cgccgo%2Cgolang&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>
> ubuntu:
> http://ubuntu-popcon.43-1.org/cgi-bin/graph.pl?name=gdc
> http://ubuntu-popcon.43-1.org/cgi-bin/graph.pl?name=golang-go
> http://ubuntu-popcon.43-1.org/cgi-bin/graph.pl?name=gccgo
>
> note that dmd is not redistributed on most linux distros due to licensing issues

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%

On Monday, 9 November 2015 at 09:19:11 UTC, Bastiaan Veelo wrote:
> Yes, use asModule() for that [1]. Not only does it enable using large grammars, it also saves compilation time for builds after the grammar has stabilised.

Thanks.

> And should the grammar still be too large, it is good to know that Pegged is good at composing a parser from different sub-grammars [2]. So the difficulty is only in finding natural boundaries at which the grammar can be split, making it work should be easy.

I knew about composition. I just wanted to keep the same names as per the original spec, instead of nesting.

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 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.

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.