www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - gdc in Linux distros recommended?

reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
I have a friend who has started writing a library in D.

Although I recommended that he should use a recent dmd or ldc, he thinks 
gdc is a better candidate because it's "available to the masses" through 
Linux distros similar to how gcc is. Although he has a good point, the 
gdc that came with his distro does not even support  nogc.

Thoughts? Can you please tell him to change his mind! :p

Ali
Oct 18 2016
next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 18 October 2016 at 23:02:28 UTC, Ali Çehreli wrote:

 I have a friend who has started writing a library in D.

 Although I recommended that he should use a recent dmd or ldc, 
 he thinks gdc is a better candidate because it's "available to 
 the masses" through Linux distros similar to how gcc is. 
 Although he has a good point, the gdc that came with his distro 
 does not even support  nogc.

 Thoughts? Can you please tell him to change his mind! :p

 Ali


That's not a very convincing argument IMO. DMD packages are 
available for download on this site. As I have learned the hard 
way, the experience isn't always the best when you rely on distro 
packagers. I once had to change distros because of a package 
maintainer that didn't care that things were broken. I would much 
rather rely on a project's own packages, because there is an 
incentive to make sure they work, they won't get abandoned, and 
the latest version is always available. There is no sense in 
which DMD is not available to the masses.
Oct 18 2016
parent reply bachmeier <no spam.net> writes:
On Tuesday, 18 October 2016 at 23:31:42 UTC, bachmeier wrote:


 That's not a very convincing argument IMO. DMD packages are 
 available for download on this site. As I have learned the hard 
 way, the experience isn't always the best when you rely on 
 distro packagers. I once had to change distros because of a 
 package maintainer that didn't care that things were broken. I 
 would much rather rely on a project's own packages, because 
 there is an incentive to make sure they work, they won't get 
 abandoned, and the latest version is always available. There is 
 no sense in which DMD is not available to the masses.


According to this page
https://gdcproject.org/downloads/
there are only distro packages for Ubuntu, Debian, and Arch. If 
that's accurate, there really is no sense in which GDC is more 
available than DMD.
Oct 18 2016
next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 19 Oct 2016 00:07:12 +0000
schrieb bachmeier <no spam.net>:


 On Tuesday, 18 October 2016 at 23:31:42 UTC, bachmeier wrote:
 

 That's not a very convincing argument IMO. DMD packages are 
 available for download on this site. As I have learned the hard 
 way, the experience isn't always the best when you rely on 
 distro packagers. I once had to change distros because of a 
 package maintainer that didn't care that things were broken. I 
 would much rather rely on a project's own packages, because 
 there is an incentive to make sure they work, they won't get 
 abandoned, and the latest version is always available. There is 
 no sense in which DMD is not available to the masses.  


 
 According to this page
 https://gdcproject.org/downloads/
 there are only distro packages for Ubuntu, Debian, and Arch. If 
 that's accurate, there really is no sense in which GDC is more 
 available than DMD.


You'll have to check the distros themselves to get the full
list. Usually, if the community is big enough, there will be
one enthusiast that thinks this Dlang thing is cool and adds a
package in some external package list.

Gentoo: https://wiki.dlang.org/GDC#Linux_distribution_packages
Mint: https://community.linuxmint.com/software/view/gdc-4.6
... just google for "<distro> gdc"

-- 
Marco
Oct 18 2016
prev sibling parent reply qznc <qznc web.de> writes:
On Wednesday, 19 October 2016 at 00:07:12 UTC, bachmeier wrote:

 According to this page
 https://gdcproject.org/downloads/
 there are only distro packages for Ubuntu, Debian, and Arch. If 
 that's accurate, there really is no sense in which GDC is more 
 available than DMD.


Yes it is. Installing gdc is just "apt install gdc" on Ubuntu 
without looking for any download sites.
Oct 19 2016
parent reply bachmeier <no spam.net> writes:
On Wednesday, 19 October 2016 at 07:37:33 UTC, qznc wrote:

 On Wednesday, 19 October 2016 at 00:07:12 UTC, bachmeier wrote:

 According to this page
 https://gdcproject.org/downloads/
 there are only distro packages for Ubuntu, Debian, and Arch. 
 If that's accurate, there really is no sense in which GDC is 
 more available than DMD.


 Yes it is. Installing gdc is just "apt install gdc" on Ubuntu 
 without looking for any download sites.


That doesn't work if you're on Fedora, opensuse, or whatever new 
distro happens to be popular this week.
Oct 19 2016
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 19.10.2016 v 12:05 bachmeier via Digitalmars-d napsal(a):


 On Wednesday, 19 October 2016 at 07:37:33 UTC, qznc wrote:

 On Wednesday, 19 October 2016 at 00:07:12 UTC, bachmeier wrote:

 According to this page
 https://gdcproject.org/downloads/
 there are only distro packages for Ubuntu, Debian, and Arch. If 
 that's accurate, there really is no sense in which GDC is more 
 available than DMD.


 Yes it is. Installing gdc is just "apt install gdc" on Ubuntu without 
 looking for any download sites.


 That doesn't work if you're on Fedora, opensuse, or whatever new 
 distro happens to be popular this week.


Not true, as my previos comment mentioned almost every popular distro 
nowdays have ldc and gdc in repositories. But only few of them have dmd
Oct 19 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 19 October 2016 at 10:15:49 UTC, Daniel Kozak wrote:

 Not true, as my previos comment mentioned almost every popular 
 distro nowdays have ldc and gdc in repositories. But only few 
 of them have dmd


most of the distros just can't. they with to repackage/rebuild 
it, and boom! it is forbidden. proprietary backend license 
seriously backstabbing dmd.
Oct 19 2016
prev sibling parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 19.10.2016 v 12:15 Daniel Kozak napsal(a):

 Dne 19.10.2016 v 12:05 bachmeier via Digitalmars-d napsal(a):


 On Wednesday, 19 October 2016 at 07:37:33 UTC, qznc wrote:

 On Wednesday, 19 October 2016 at 00:07:12 UTC, bachmeier wrote:

 According to this page
 https://gdcproject.org/downloads/
 there are only distro packages for Ubuntu, Debian, and Arch. If 
 that's accurate, there really is no sense in which GDC is more 
 available than DMD.


 Yes it is. Installing gdc is just "apt install gdc" on Ubuntu 
 without looking for any download sites.


 That doesn't work if you're on Fedora, opensuse, or whatever new 
 distro happens to be popular this week.


 Not true, as my previos comment mentioned almost every popular distro 
 nowdays have ldc and gdc in repositories. But only few of them have dmd


Btw. I belive that future is in http://flatpak.org or similar concepts
Oct 19 2016
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tuesday, October 18, 2016 16:02:28 Ali Çehreli via Digitalmars-d wrote:

 I have a friend who has started writing a library in D.

 Although I recommended that he should use a recent dmd or ldc, he thinks
 gdc is a better candidate because it's "available to the masses" through
 Linux distros similar to how gcc is. Although he has a good point, the
 gdc that came with his distro does not even support  nogc.

 Thoughts? Can you please tell him to change his mind! :p


I don't know what the whole situation is with gdc right now, but clearly,
they're seriously undermanned, because they're still at 2.066 and haven't
managed to move to a version of the front-end that's written in D. You
certainly _can_ use it, but I'd argue that it's way to old to even consider
it. dmd 2.066.1 was released two years ago this month. So, gdc is old enough
now that it's possible for a symbol in druntime or Phobos to have gone
through the entire deprecation cycle from start to finish between the time
that that version of druntime/Phobos was released and the upcoming release
of dmd. D is _way_ more stable than it used to be, but it still changes at
far too fast a pace for you not to have trouble if you're trying to use a
two year old compiler. And when you consider stuff like code.dlang.org, it
gets even worse, since a lot of that stuff works with only the most recent
release or two of dmd (certainly, most projects don't try and maintain
compatibility over more than that). So, if you insist on using gdc, you're
pretty much cutting yourself off from a large portion of the existing D
ecosystem.

I would love to see gdc finally get up-to-date and usable, but it's just way
to old. And it's downright trivial to install dmd, making concerns about
what's in your distro's repo kind of silly. With dmd, you can just take the
zip/tar.xz file, decompress it, and add the appropriate bin directory from
it to your PATH, and you're good to go. And there are packages for several
distros as well if you want to use your package manager to install it that
way (a few distros even have it in their repo). And I don't think that
installing LDC is much harder. And looking at their site, it looks like
several distros have LDC in their repos if you want to grab whatever version
they have rather than installing the latest manually. So, if you want an
alternative to dmd, LDC has been doing a good job of being up-to-date and is
quite available.

Honestly, until gdc is able to be at least _close_ to up-to-date, I don't
see any reason to use it. You're just causing yourself problems for no gain.
I very much hope that the gdc maintainers will get whatever help they need
and will finally be able to get gdc up-to-date one of these days soon, but
until then, I wouldn't mess with it. And honestly, I find the fact that
they're still stuck on 2.066.1 to be very concerning.

- Jonathan M Davis
Oct 18 2016
prev sibling next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 18 Oct 2016 16:02:28 -0700
schrieb Ali =C3=87ehreli <acehreli yahoo.com>:


 I have a friend who has started writing a library in D.
=20
 Although I recommended that he should use a recent dmd or ldc, he thinks=


=20

 gdc is a better candidate because it's "available to the masses" through=


=20

 Linux distros similar to how gcc is. Although he has a good point, the=20
 gdc that came with his distro does not even support  nogc.
=20
 Thoughts? Can you please tell him to change his mind! :p
=20
 Ali


If he is starting right *now*, missing fixes or language
enhancements will cause confusion when he asks questions on
the newsgroup or on IRC. (But he has you for that, right?)

Back in the days I would have opted for GDC, too. It didn't
lag far behind and I had hopes that it would get merged into
GCC for good, meaning it would become the de facto D compiler
on GNU systems.

Nowadays I also see the large version gap and that it still
hasn't been merged into mainline GCC. On the other hand LDC
subjectively offers a couple more D specific enhancements,
like turning GC allocations into stack allocations in trivial
cases or the long list of compiler flags. Also with the
backend being a library it is more flexible in the context of
updating the front-end independently from the backend, which
fits Dlang's development cycle better IMO.

I'd say start with DMD, as it comes practically free of
dependencies and is the fastest compiler, which may be the
most useful aspect when you start to learn the language and
need to iterate often.

--=20
Marco
Oct 18 2016
next sibling parent reply TheGag96 <thegag96 gmail.com> writes:
On Wednesday, 19 October 2016 at 03:29:10 UTC, Marco Leise wrote:

 On the other hand LDC subjectively offers a couple more D 
 specific enhancements, like turning GC allocations into stack 
 allocations in trivial cases


Whoa, seriously? I know it's a bit off-topic, but do you have a 
code example of where this would happen? That's amazing!
Oct 19 2016
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 19 October 2016 at 21:25, TheGag96 via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 19 October 2016 at 03:29:10 UTC, Marco Leise wrote:

 On the other hand LDC subjectively offers a couple more D specific
 enhancements, like turning GC allocations into stack allocations in trivial
 cases



 Whoa, seriously? I know it's a bit off-topic, but do you have a code example
 of where this would happen? That's amazing!


Not to be the one to downplay something.  But it's actually pretty boring. ;-)

An example in GDC would be where a closure was created, but the
nesting function was inlined or optimized away.

In the latter case, you may see something like the following in the DCE pass.

int foo()
{
  closure = _d_allocmemory (8);
  closure.bar = 0;

  return 0;
}

Using a mixture of having a closure that is set but never read, and
giving the optimizer the right hints about what "allocmemory" does
means that it removes the call as dead code.

The exact same is done in the former case, you just convert the
closure to a stack frame, removing the dead call the allocmemory.
Oct 19 2016
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 19 Oct 2016 19:25:39 +0000
schrieb TheGag96 <thegag96 gmail.com>:


 On Wednesday, 19 October 2016 at 03:29:10 UTC, Marco Leise wrote:

 On the other hand LDC subjectively offers a couple more D 
 specific enhancements, like turning GC allocations into stack 
 allocations in trivial cases  


 
 Whoa, seriously? I know it's a bit off-topic, but do you have a 
 code example of where this would happen? That's amazing!


 
Sorry, I don't have a concrete example. David Nadlinger keeps
emphasizing that the escape analysis is extremely simple. Try
a function with only "auto test = new Object;" in it and
extend from there using the "-vgc" switch to see when it
starts to fail.

-- 
Marco
Oct 19 2016
prev sibling parent David Nadlinger <code klickverbot.at> writes:
On Wednesday, 19 October 2016 at 03:29:10 UTC, Marco Leise wrote:

 I'd say start with DMD, as it comes practically free of 
 dependencies […]


The same applies to LDC. If you want, you can use the 
self-contained binary releases, which just require the system 
linker to be present, like DMD does.

  — David
Oct 19 2016
prev sibling next sibling parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 19.10.2016 v 01:02 Ali Çehreli via Digitalmars-d napsal(a):


 I have a friend who has started writing a library in D.

 Although I recommended that he should use a recent dmd or ldc, he 
 thinks gdc is a better candidate because it's "available to the 
 masses" through Linux distros similar to how gcc is.


No, gdc is not part of gcc, so there is no difference between ldc or gdc 
(dmd has some license issue for some package maintainers).  I have 
looked at top 10 linux distro at distrowatch.com and in every of them 
(excluding centos), there are packages for ldc and gdc, but in OpenSuse 
there is only ldc. So from that point ldc is much more available to the 
masses
Oct 18 2016
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Tuesday, 18 October 2016 at 23:02:28 UTC, Ali Çehreli wrote:

 I have a friend who has started writing a library in D.

 Although I recommended that he should use a recent dmd or ldc, 
 he thinks gdc is a better candidate because it's "available to 
 the masses" through Linux distros similar to how gcc is. 
 Although he has a good point, the gdc that came with his distro 
 does not even support  nogc.

 Thoughts? Can you please tell him to change his mind! :p

 Ali


For an example, Fedora's default repository ONLY has LDC, because 
GDC is not yet merged into GCC. The reason why Ubuntu does is 
because they have relaxed policy regarding GCC.

I think LDC is in most major distros, GDC is not, so LDC is the 
clear winner here. I build GDC myself and use it on Fedora, it is 
pretty straightforward, but I would recommend LDC to beginners. 
Once GDC is merged into GCC, it is a no-brainer - GCC/GDC all the 
way!
Oct 19 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 19 October 2016 at 10:21:43 UTC, Dejan Lekic wrote:

 because GDC is not yet merged into GCC.


there is absolutely no reason to do this. while today the 
question of syncing gdc frontend with dmd is only a question of 
manpower, with such a merge gdc will *always* be behind, stucked 
with old versions. and for D this is critical, as each new D 
version brings something better, fix some bugs and so on. it's 
not like C, for example, for which you don't have new 
language/stdlib release each several monthes.

tl;dr: if gdc will be merged to gcc, it will be bad for D, and 
unrecoverable death for gdc.
Oct 19 2016
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 10/18/2016 07:02 PM, Ali Çehreli wrote:

 I have a friend who has started writing a library in D.

 Although I recommended that he should use a recent dmd or ldc, he thinks
 gdc is a better candidate because it's "available to the masses" through
 Linux distros similar to how gcc is. Although he has a good point, the
 gdc that came with his distro does not even support  nogc.

 Thoughts? Can you please tell him to change his mind! :p

 Ali


The last GDC release is stuck all the way back at DMDFE v2.066, which is 
over two years old. Very few libs/projects are going to still be 
supporting that, there's just too much limitation going back that far. 
LDC had been keeping up much better.

Due to incompatibilities and necessary features/bugfixes, pretty much 
all of my projects have already been forced to drop support for DMDFE 
v2.066, and GDC in the process. And I *prefer* to maintain compatibility 
as far back as I can.

If his lib isn't tested to support up-to-date D compilers (especially 
the import changes in 2.070, but there's other stuff as well), that's 
going to prevent a lot of people from being able to use his lib. So much 
for availability to the masses.

And LDC (and DMD, frankly) is every bit as "available to the masses" as 
GDC. The "available to the masses" just seems based more on general 
perception of "GCC" being a big, major name rather than anything concrete.
Oct 19 2016
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 19 October 2016 at 18:01, Nick Sabalausky via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 10/18/2016 07:02 PM, Ali Çehreli wrote:

 I have a friend who has started writing a library in D.

 Although I recommended that he should use a recent dmd or ldc, he thinks
 gdc is a better candidate because it's "available to the masses" through
 Linux distros similar to how gcc is. Although he has a good point, the
 gdc that came with his distro does not even support  nogc.

 Thoughts? Can you please tell him to change his mind! :p

 Ali



 The last GDC release is stuck all the way back at DMDFE v2.066, which is
 over two years old. Very few libs/projects are going to still be supporting
 that, there's just too much limitation going back that far. LDC had been
 keeping up much better.


The core devs are becoming much more receptive to the idea of a
release that has fixes maintained for longer periods of time.  While I
welcome this, it may have come too little, too late.

And GDC is using the 2.068 feature set, plus a lot of bug fixes from
later versions.  I guess you could call it 2.068.5.  :-)


 Due to incompatibilities and necessary features/bugfixes, pretty much all of
 my projects have already been forced to drop support for DMDFE v2.066, and
 GDC in the process. And I *prefer* to maintain compatibility as far back as
 I can.

 If his lib isn't tested to support up-to-date D compilers (especially the
 import changes in 2.070, but there's other stuff as well), that's going to
 prevent a lot of people from being able to use his lib. So much for
 availability to the masses.


The fixes to import behaviour only breaks forwards compatibility, not
backwards compatibility.

The problem with compatibility is a library problem, not a compiler IMO.
Oct 19 2016
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 10/19/2016 05:13 PM, Iain Buclaw via Digitalmars-d wrote:

 On 19 October 2016 at 18:01, Nick Sabalausky via Digitalmars-d

 The last GDC release is stuck all the way back at DMDFE v2.066, which is
 over two years old. Very few libs/projects are going to still be supporting
 that, there's just too much limitation going back that far. LDC had been
 keeping up much better.




...

 And GDC is using the 2.068 feature set, plus a lot of bug fixes from
 later versions.  I guess you could call it 2.068.5.  :-)


Maybe there's a certain amount of truth to that, but not completely: In 
all my projects anyway, the latest available GDC on travis always broke 
at exactly the same time DMD 2.066 and below broke. I don't think I have 
any remaining projects that still work on GDC, but several still work on 
DMD 2.067.1 (not sure about 2.067.0, don't use that one in my 
.travis.yml files since 2.067.1 came out).

Maybe there's a newer GDC build that isn't on travis yet? Current 
lastest (using "gdc" in .travis.yml), checked as of 13 hours ago, is 
reporting this:

gdc (crosstool-NG crosstool-ng-1.20.0-232-gc746732 - 
20150825-2.066.1-58ec4c13ec) 4.9.3

There's also a "gdc-5.2.0" that (checked as of this past April, anyway - 
not sure if there would be a newer "gdc-5.2.0" though), reports:

gdc (crosstool-NG crosstool-ng-1.20.0-232-gc746732 - 
20150825-2.066.1-dadb5a3784) 5.2.0



 If his lib isn't tested to support up-to-date D compilers (especially the
 import changes in 2.070, but there's other stuff as well), that's going to
 prevent a lot of people from being able to use his lib. So much for
 availability to the masses.


 The fixes to import behaviour only breaks forwards compatibility, not
 backwards compatibility.


Not sure what your point is here. If you're writing a library and want 
to avoid giving your users deprecation messages due to the import 
changes, then you need to test on 2.070 or newer. Clean compilation on 
pre-2.070 does not guarantee clean compilation on 2.070+.


 The problem with compatibility is a library problem, not a compiler IMO.


Since compiler versions and druntime/phobos versions are still pretty 
much a packaged deal, the distinction is irrelevent.
Oct 19 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thursday, 20 October 2016 at 05:43:47 UTC, Nick Sabalausky 
wrote:

 And GDC is using the 2.068 feature set, plus a lot of bug 
 fixes from
 later versions.  I guess you could call it 2.068.5.  :-)


 Maybe there's a certain amount of truth to that, but not 
 completely: In all my projects anyway, the latest available GDC 
 on travis always broke at exactly the same time DMD 2.066 and 
 below broke.


i believe that Iain talked about frontend features. phobos is 
still at 2.066, i think.


 Not sure what your point is here. If you're writing a library 
 and want to avoid giving your users deprecation messages due to 
 the import changes, then you need to test on 2.070 or newer. 
 Clean compilation on pre-2.070 does not guarantee clean 
 compilation on 2.070+.


actually, any import deprecation messages may come only from 
sloppy coding, like using "implicitly imported identifier from 
3rd module". tbh, none of my code ever triggered such a warning 
when DMD finally (almost) fixed it's import scheme. not 'cause i 
am a brilliant, but 'cause doing it "D way" (local selective 
imports in the closest scope) almost automatically prevents such 
bugs.
Oct 20 2016
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 10/20/2016 08:21 AM, ketmar wrote:

 On Thursday, 20 October 2016 at 05:43:47 UTC, Nick Sabalausky wrote:

 Not sure what your point is here. If you're writing a library and want
 to avoid giving your users deprecation messages due to the import
 changes, then you need to test on 2.070 or newer. Clean compilation on
 pre-2.070 does not guarantee clean compilation on 2.070+.


 actually, any import deprecation messages may come only from sloppy
 coding, like using "implicitly imported identifier from 3rd module".
 tbh, none of my code ever triggered such a warning when DMD finally
 (almost) fixed it's import scheme. not 'cause i am a brilliant, but
 'cause doing it "D way" (local selective imports in the closest scope)
 almost automatically prevents such bugs.


I hit tons of messages, mostly because of FQN now being more broken than 
ever.
Oct 20 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thursday, 20 October 2016 at 16:03:32 UTC, Nick Sabalausky 
wrote:

 On 10/20/2016 08:21 AM, ketmar wrote:

 On Thursday, 20 October 2016 at 05:43:47 UTC, Nick Sabalausky 
 wrote:

 Not sure what your point is here. If you're writing a library 
 and want
 to avoid giving your users deprecation messages due to the 
 import
 changes, then you need to test on 2.070 or newer. Clean 
 compilation on
 pre-2.070 does not guarantee clean compilation on 2.070+.


 actually, any import deprecation messages may come only from 
 sloppy
 coding, like using "implicitly imported identifier from 3rd 
 module".
 tbh, none of my code ever triggered such a warning when DMD 
 finally
 (almost) fixed it's import scheme. not 'cause i am a 
 brilliant, but
 'cause doing it "D way" (local selective imports in the 
 closest scope)
 almost automatically prevents such bugs.


 I hit tons of messages, mostly because of FQN now being more 
 broken than ever.


that's why i added "(almost)" part. there was another word, but i 
did self-censoring.
Oct 20 2016
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 20 Oct 2016 12:21:34 +0000
schrieb ketmar <ketmar ketmar.no-ip.org>:


 On Thursday, 20 October 2016 at 05:43:47 UTC, Nick Sabalausky 
 wrote:

 And GDC is using the 2.068 feature set, plus a lot of bug 
 fixes from
 later versions.  I guess you could call it 2.068.5.  :-)
  


 Maybe there's a certain amount of truth to that, but not 
 completely: In all my projects anyway, the latest available GDC 
 on travis always broke at exactly the same time DMD 2.066 and 
 below broke.  


 
 i believe that Iain talked about frontend features. phobos is 
 still at 2.066, i think.


GDC git is completely 2.068.2. There are no updated binary releases as
there's still one remaining blocker regression (32bit only).
Oct 21 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Friday, 21 October 2016 at 19:53:14 UTC, Johannes Pfau wrote:

 GDC git is completely 2.068.2. There are no updated binary 
 releases as there's still one remaining blocker regression 
 (32bit only).


sorry for spreading false info then.
Oct 21 2016