digitalmars.D.announce - dmd 2.065.0
- Andrew Edwards (34/34) Feb 24 2014 The final release of DMD 2.065 is now available. [1] contains complete
- simendsjo (3/6) Feb 24 2014 Great news! Your changelog link has a typo, and it's not updated for 2.0...
- Kelet (2/2) Feb 24 2014 \o/ Congrats! I'm excited for this release, it fixes a good
- extrawurst (3/9) Feb 24 2014 Actually no, there is still just 2.064 on the download page
- Szymon Gatner (4/33) Feb 24 2014 [1] gives:
- Francesco Cattoglio (6/38) Feb 24 2014 Indeed, it's a mispelling, and the changelog.html is not yet
- Szymon Gatner (6/48) Feb 24 2014 I love these ChangeLogs! Really great things for a person that
- Kapps (3/5) Feb 24 2014 Correct. The pull for it is
- Szymon Gatner (2/8) Feb 24 2014 Clear, thanks. 2.066 then I suppose?
- Szymon Gatner (2/8) Feb 24 2014 Clear, thanks. 2.066 then I suppose?
- Namespace (2/11) Feb 24 2014 Let us hope so!
- Namespace (5/11) Feb 24 2014 Not really. This pull introduce the virtual keyword. The next
- Szymon Gatner (2/14) Feb 24 2014 Yes yes, I understand :)
- Leandro Lucarella (10/24) Feb 24 2014 Wait, what? That was one of C++ biggest mistakes! You are seriously
- Namespace (4/25) Feb 24 2014 Don't worry:
- Francesco Cattoglio (4/8) Feb 24 2014 Wait, does this mean we finally came to some kind of agreement on
- Andrei Alexandrescu (3/9) Feb 24 2014 Not finally... virtually :o).
- Joseph Cassman (4/19) Feb 24 2014 Not bad. :-)
- Andrew Edwards (3/6) Feb 24 2014 Correction: http://dlang.org/changelog.html
- Tourist (3/6) Feb 24 2014 The .zip file for Windows isn't listed on the download page.
- Dominikus Dittes Scherkl (7/8) Feb 24 2014 Cool.
- Dicebot (1/1) Feb 24 2014 Arch packages have just been updated.
- Mike (3/4) Feb 24 2014 Thank You!
- Manu (5/39) Feb 24 2014 Awesome!
- Brad Anderson (2/9) Feb 24 2014 Nope, not a regression. That never got implemented.
- Walter Bright (2/8) Feb 24 2014 Is there a bugzilla issue for this?
- Brad Anderson (2/14) Feb 25 2014 Nope.
- Walter Bright (2/14) Feb 25 2014 Please make one - otherwise it'll get overlooked.
- Brad Anderson (4/5) Feb 24 2014 Thanks for all your hard work, Andrew. Seems like Martin and Nick
- Jordi Sayol (5/6) Feb 24 2014 Congratulations for this new dmd release!
- Walter Bright (3/3) Feb 24 2014 Looks like we need to do something about this:
- Steven Schveighoffer (7/10) Feb 24 2014 I think the change should go (if it was intentional).
- Meta (6/11) Feb 24 2014 Why *was* there a change to enforce that AA keys have opCmp? It
- Steven Schveighoffer (8/20) Feb 24 2014 A wild wild guess is that there was code in the compiler that used to
- Meta (5/12) Feb 24 2014 Ah, I see. I got the impression that he thought it was a
- Steven Schveighoffer (3/6) Feb 24 2014 I did, but I have a feeling it won't help :)
- Daniel Murphy (5/9) Feb 25 2014 Walter + Andrei did it, and it was completely intentional, and it was kn...
- Dicebot (5/8) Feb 25 2014 I find it so ironical that Walter warns that this may break the
- Steven Schveighoffer (12/21) Feb 25 2014 This was the wrong fix. Druntime should be modified to use TypeInfo.equa...
- Steven Schveighoffer (5/7) Feb 25 2014 Sorry, I meant define opCmp but not opEquals. Some types can be compared...
- Walter Bright (3/6) Feb 25 2014 It was intended to only break code that was already broken (would fail a...
- Steven Schveighoffer (29/37) Feb 25 2014 I just wrote this and compiled on 2.064:
- Jacob Carlborg (12/38) Feb 25 2014 The thing is that the compiler complains about a deceleration looking
- Steven Schveighoffer (13/22) Feb 25 2014 If the compiler generates opEquals and opCmp, then it's guaranteed
- Jacob Carlborg (5/9) Feb 26 2014 Filed as [1]. Unfortunately I wasn't able to find a reduced test case.
- Jacob Carlborg (8/11) Feb 25 2014 I've been compiling Tango with the latest version for a couple of
- Jacob Carlborg (18/21) Feb 25 2014 Answering some of your comments here:
- Iain Buclaw (7/31) Feb 25 2014 +1
- Walter Bright (2/5) Feb 25 2014 https://d.puremagic.com/issues/show_bug.cgi?id=12255
- Rory McGuire (5/39) Feb 24 2014 BTW it seems the copyright notice is outdated:
- Jonathan Dunlap (3/3) Feb 24 2014 Great work! It warms my heart to see D improving at a steady
- Walter Bright (3/5) Feb 24 2014 Thank you, everyone, for this release! And a special thanks to Andrew wh...
- Joakim (8/11) Feb 25 2014 Nice job wrangling the new release schedule and shepherding your
- Dmitry Olshansky (8/12) Feb 25 2014 Awesome.
- =?UTF-8?B?IlRow6lv?= Bueno" (14/17) Mar 28 2014 I am having an issue with the windows installer :
- =?UTF-8?B?IlRow6lv?= Bueno" (11/12) Mar 29 2014 Ok, so after investigations I partially fixed my problem :
- Brad Anderson (4/17) Apr 01 2014 The current plan (by me at least) is to just do away with the
- =?UTF-8?B?IlRow6lv?= Bueno" (4/25) Apr 02 2014 Would be the best indeed. An online installer is not useful in
The final release of DMD 2.065 is now available. [1] contains complete
descriptions of all changes, enhancements and fixes for this release.
Available binaries can be accessed at [2]. Since the website will lag
slightly behind, links are provided below for convenience.
All Systems:
http://ftp.digitalmars.com/dmd.2.065.0.zip
FreeBSD:
http://ftp.digitalmars.com/dmd.2.065.0.freebsd-64.zip
http://ftp.digitalmars.com/dmd.2.065.0.freebsd-32.zip
Linux:
http://ftp.digitalmars.com/dmd_2.065.0-0_i386.deb
http://ftp.digitalmars.com/dmd_2.065.0-0_amd64.deb
http://ftp.digitalmars.com/dmd-2.065.0-0.fedora.i386.rpm
http://ftp.digitalmars.com/dmd-2.065.0-0.fedora.x86_64.rpm
http://ftp.digitalmars.com/dmd-2.065.0-0.openSUSE.i386.rpm
http://ftp.digitalmars.com/dmd-2.065.0-0.openSUSE.x86_64.rpm
http://ftp.digitalmars.com/dmd.2.065.0.linux.zip
MAC OS X:
http://ftp.digitalmars.com/dmd.2.065.0.dmg
http://ftp.digitalmars.com/dmd.2.065.0.osx.zip
Windows:
http://ftp.digitalmars.com/dmd-2.065.0.exe
http://ftp.digitalmars.com/dmd.2.065.0.windows.zip
[1] http://dlang.org/chagelog.html
[2] http://dlang.org/download.html
Regards,
Andrew
--
--------------------
http://www.akeron.co
auto getAddress() {
string location = " ", period = ".";
return ("info" ~ location ~ "afidem" ~ period ~ "org");
}
Feb 24 2014
simendsjo <simendsjo gmail.com> On 02/24/2014 09:45 AM, Andrew Edwards wrote:The final release of DMD 2.065 is now available. [1] contains complete descriptions of all changes, enhancements and fixes for this release.(...)[1] http://dlang.org/chagelog.htmlGreat news! Your changelog link has a typo, and it's not updated for 2.065.
Feb 24 2014
\o/ Congrats! I'm excited for this release, it fixes a good amount of bugs that have been plaguing me.
Feb 24 2014
On Monday, 24 February 2014 at 08:45:31 UTC, Andrew Edwards wrote:The final release of DMD 2.065 is now available. [1] contains complete descriptions of all changes, enhancements and fixes for this release.Awesome release!Available binaries can be accessed at [2]. Since the website will lag slightly behind, links are provided below for convenience.Actually no, there is still just 2.064 on the download page
Feb 24 2014
On Monday, 24 February 2014 at 08:45:31 UTC, Andrew Edwards wrote:The final release of DMD 2.065 is now available. [1] contains complete descriptions of all changes, enhancements and fixes for this release. Available binaries can be accessed at [2]. Since the website will lag slightly behind, links are provided below for convenience. All Systems: http://ftp.digitalmars.com/dmd.2.065.0.zip FreeBSD: http://ftp.digitalmars.com/dmd.2.065.0.freebsd-64.zip http://ftp.digitalmars.com/dmd.2.065.0.freebsd-32.zip Linux: http://ftp.digitalmars.com/dmd_2.065.0-0_i386.deb http://ftp.digitalmars.com/dmd_2.065.0-0_amd64.deb http://ftp.digitalmars.com/dmd-2.065.0-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.065.0-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd-2.065.0-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.065.0-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd.2.065.0.linux.zip MAC OS X: http://ftp.digitalmars.com/dmd.2.065.0.dmg http://ftp.digitalmars.com/dmd.2.065.0.osx.zip Windows: http://ftp.digitalmars.com/dmd-2.065.0.exe http://ftp.digitalmars.com/dmd.2.065.0.windows.zip [1] http://dlang.org/chagelog.html [2] http://dlang.org/download.html Regards, Andrew[1] gives: Not Found The requested URL /chagelog.html was not found on this server.
Feb 24 2014
On Monday, 24 February 2014 at 10:33:27 UTC, Szymon Gatner wrote:Indeed, it's a mispelling, and the changelog.html is not yet updated. However, you can download the zip and find the correct, updated changelog from the [zipfile.zip]/html/d/ folder Very nice work! 280+ issues closed for DMD, 80+ issues closed for phobos. Thank you to all the contributors!All Systems: http://ftp.digitalmars.com/dmd.2.065.0.zip FreeBSD: http://ftp.digitalmars.com/dmd.2.065.0.freebsd-64.zip http://ftp.digitalmars.com/dmd.2.065.0.freebsd-32.zip Linux: http://ftp.digitalmars.com/dmd_2.065.0-0_i386.deb http://ftp.digitalmars.com/dmd_2.065.0-0_amd64.deb http://ftp.digitalmars.com/dmd-2.065.0-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.065.0-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd-2.065.0-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.065.0-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd.2.065.0.linux.zip MAC OS X: http://ftp.digitalmars.com/dmd.2.065.0.dmg http://ftp.digitalmars.com/dmd.2.065.0.osx.zip Windows: http://ftp.digitalmars.com/dmd-2.065.0.exe http://ftp.digitalmars.com/dmd.2.065.0.windows.zip [1] http://dlang.org/chagelog.html [2] http://dlang.org/download.html Regards, Andrew[1] gives: Not Found The requested URL /chagelog.html was not found on this server.
Feb 24 2014
On Monday, 24 February 2014 at 10:43:32 UTC, Francesco Cattoglio wrote:On Monday, 24 February 2014 at 10:33:27 UTC, Szymon Gatner wrote:I love these ChangeLogs! Really great things for a person that still learns D. So 2.065 is not the one that will make class methods final by default?Indeed, it's a mispelling, and the changelog.html is not yet updated. However, you can download the zip and find the correct, updated changelog from the [zipfile.zip]/html/d/ folder Very nice work! 280+ issues closed for DMD, 80+ issues closed for phobos. Thank you to all the contributors!All Systems: http://ftp.digitalmars.com/dmd.2.065.0.zip FreeBSD: http://ftp.digitalmars.com/dmd.2.065.0.freebsd-64.zip http://ftp.digitalmars.com/dmd.2.065.0.freebsd-32.zip Linux: http://ftp.digitalmars.com/dmd_2.065.0-0_i386.deb http://ftp.digitalmars.com/dmd_2.065.0-0_amd64.deb http://ftp.digitalmars.com/dmd-2.065.0-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.065.0-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd-2.065.0-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.065.0-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd.2.065.0.linux.zip MAC OS X: http://ftp.digitalmars.com/dmd.2.065.0.dmg http://ftp.digitalmars.com/dmd.2.065.0.osx.zip Windows: http://ftp.digitalmars.com/dmd-2.065.0.exe http://ftp.digitalmars.com/dmd.2.065.0.windows.zip [1] http://dlang.org/chagelog.html [2] http://dlang.org/download.html Regards, Andrew[1] gives: Not Found The requested URL /chagelog.html was not found on this server.
Feb 24 2014
On Monday, 24 February 2014 at 11:04:14 UTC, Szymon Gatner wrote:So 2.065 is not the one that will make class methods final by default?Correct. The pull for it is https://github.com/D-Programming-Language/dmd/pull/2895
Feb 24 2014
On Monday, 24 February 2014 at 11:21:32 UTC, Kapps wrote:On Monday, 24 February 2014 at 11:04:14 UTC, Szymon Gatner wrote:Clear, thanks. 2.066 then I suppose?So 2.065 is not the one that will make class methods final by default?Correct. The pull for it is https://github.com/D-Programming-Language/dmd/pull/2895
Feb 24 2014
On Monday, 24 February 2014 at 11:21:32 UTC, Kapps wrote:On Monday, 24 February 2014 at 11:04:14 UTC, Szymon Gatner wrote:Clear, thanks. 2.066 then I suppose?So 2.065 is not the one that will make class methods final by default?Correct. The pull for it is https://github.com/D-Programming-Language/dmd/pull/2895
Feb 24 2014
On Monday, 24 February 2014 at 11:44:30 UTC, Szymon Gatner wrote:On Monday, 24 February 2014 at 11:21:32 UTC, Kapps wrote:Let us hope so!On Monday, 24 February 2014 at 11:04:14 UTC, Szymon Gatner wrote:Clear, thanks. 2.066 then I suppose?So 2.065 is not the one that will make class methods final by default?Correct. The pull for it is https://github.com/D-Programming-Language/dmd/pull/2895
Feb 24 2014
On Monday, 24 February 2014 at 11:21:32 UTC, Kapps wrote:On Monday, 24 February 2014 at 11:04:14 UTC, Szymon Gatner wrote:Not really. This pull introduce the virtual keyword. The next step will afaik force you to write on every method if it is virtual or final. The step afterwards will probably introduce final by default.So 2.065 is not the one that will make class methods final by default?Correct. The pull for it is https://github.com/D-Programming-Language/dmd/pull/2895
Feb 24 2014
On Monday, 24 February 2014 at 11:45:20 UTC, Namespace wrote:On Monday, 24 February 2014 at 11:21:32 UTC, Kapps wrote:Yes yes, I understand :)On Monday, 24 February 2014 at 11:04:14 UTC, Szymon Gatner wrote:Not really. This pull introduce the virtual keyword. The next step will afaik force you to write on every method if it is virtual or final. The step afterwards will probably introduce final by default.So 2.065 is not the one that will make class methods final by default?Correct. The pull for it is https://github.com/D-Programming-Language/dmd/pull/2895
Feb 24 2014
Szymon Gatner, el 24 de February a las 11:48 me escribiste:On Monday, 24 February 2014 at 11:45:20 UTC, Namespace wrote:Wait, what? That was one of C++ biggest mistakes! You are seriously wanting to do that? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- O.K. Just a little pinprick. There'll be no more aaaaaaaaah! But you may feel a little sick.On Monday, 24 February 2014 at 11:21:32 UTC, Kapps wrote:On Monday, 24 February 2014 at 11:04:14 UTC, Szymon Gatner wrote:Not really. This pull introduce the virtual keyword. The next step will afaik force you to write on every method if it is virtual or final. The step afterwards will probably introduce final by default.So 2.065 is not the one that will make class methods final by default?Correct. The pull for it is https://github.com/D-Programming-Language/dmd/pull/2895
Feb 24 2014
On Tuesday, 25 February 2014 at 00:09:45 UTC, Leandro Lucarella wrote:Szymon Gatner, el 24 de February a las 11:48 me escribiste:Don't worry: https://d.puremagic.com/issues/show_bug.cgi?id=11616#c3On Monday, 24 February 2014 at 11:45:20 UTC, Namespace wrote:Wait, what? That was one of C++ biggest mistakes! You are seriously wanting to do that?On Monday, 24 February 2014 at 11:21:32 UTC, Kapps wrote:On Monday, 24 February 2014 at 11:04:14 UTC, Szymon Gatner wrote:Not really. This pull introduce the virtual keyword. The next step will afaik force you to write on every method if it is virtual or final. The step afterwards will probably introduce final by default.So 2.065 is not the one that will make class methods final by default?Correct. The pull for it is https://github.com/D-Programming-Language/dmd/pull/2895
Feb 24 2014
On Monday, 24 February 2014 at 11:45:20 UTC, Namespace wrote:Not really. This pull introduce the virtual keyword. The next step will afaik force you to write on every method if it is virtual or final. The step afterwards will probably introduce final by default.Wait, does this mean we finally came to some kind of agreement on the whole debate? I was sure that any kind of change of current behaviour was being vetoed
Feb 24 2014
On 2/24/14, 4:24 AM, Francesco Cattoglio wrote:On Monday, 24 February 2014 at 11:45:20 UTC, Namespace wrote:Not finally... virtually :o). AndreiNot really. This pull introduce the virtual keyword. The next step will afaik force you to write on every method if it is virtual or final. The step afterwards will probably introduce final by default.Wait, does this mean we finally came to some kind of agreement on the whole debate?
Feb 24 2014
On Monday, 24 February 2014 at 18:58:50 UTC, Andrei Alexandrescu wrote:On 2/24/14, 4:24 AM, Francesco Cattoglio wrote:Not bad. :-) JosephOn Monday, 24 February 2014 at 11:45:20 UTC, Namespace wrote:Not finally... virtually :o). AndreiNot really. This pull introduce the virtual keyword. The next step will afaik force you to write on every method if it is virtual or final. The step afterwards will probably introduce final by default.Wait, does this mean we finally came to some kind of agreement on the whole debate?
Feb 24 2014
On 2/24/14, 3:45 AM, Andrew Edwards wrote:The final release of DMD 2.065 is now available. [1] contains complete descriptions of all changes, enhancements and fixes for this release. [1] http://dlang.org/chagelog.htmlCorrection: http://dlang.org/changelog.html Note that this page is still pinging update to 2.065.
Feb 24 2014
On Monday, 24 February 2014 at 08:45:31 UTC, Andrew Edwards wrote:Windows: http://ftp.digitalmars.com/dmd-2.065.0.exe http://ftp.digitalmars.com/dmd.2.065.0.windows.zipThe .zip file for Windows isn't listed on the download page. http://dlang.org/download.html
Feb 24 2014
On Monday, 24 February 2014 at 08:45:31 UTC, Andrew Edwards wrote:The final release of DMD 2.065 is now available.Cool. I found two bugs in the comments to library changes point 2. The 2nd comment says "all values are not true" but what the check does is "not all values are true". Same for the 4th comment: "all values do not convert to true" should be "not all values convert to true".
Feb 24 2014
On Monday, 24 February 2014 at 17:37:08 UTC, Dicebot wrote:Arch packages have just been updated.Thank You! Mike
Feb 24 2014
Awesome!
First thing I noticed though, the Windows installer seemed to forget where
my existing D installation is, and tried to install it somewhere else.
I thought this got fixed months ago? Regression in the installer?
On 24 February 2014 18:45, Andrew Edwards <ridimz yahoo.com> wrote:
The final release of DMD 2.065 is now available. [1] contains complete
descriptions of all changes, enhancements and fixes for this release.
Available binaries can be accessed at [2]. Since the website will lag
slightly behind, links are provided below for convenience.
All Systems:
http://ftp.digitalmars.com/dmd.2.065.0.zip
FreeBSD:
http://ftp.digitalmars.com/dmd.2.065.0.freebsd-64.zip
http://ftp.digitalmars.com/dmd.2.065.0.freebsd-32.zip
Linux:
http://ftp.digitalmars.com/dmd_2.065.0-0_i386.deb
http://ftp.digitalmars.com/dmd_2.065.0-0_amd64.deb
http://ftp.digitalmars.com/dmd-2.065.0-0.fedora.i386.rpm
http://ftp.digitalmars.com/dmd-2.065.0-0.fedora.x86_64.rpm
http://ftp.digitalmars.com/dmd-2.065.0-0.openSUSE.i386.rpm
http://ftp.digitalmars.com/dmd-2.065.0-0.openSUSE.x86_64.rpm
http://ftp.digitalmars.com/dmd.2.065.0.linux.zip
MAC OS X:
http://ftp.digitalmars.com/dmd.2.065.0.dmg
http://ftp.digitalmars.com/dmd.2.065.0.osx.zip
Windows:
http://ftp.digitalmars.com/dmd-2.065.0.exe
http://ftp.digitalmars.com/dmd.2.065.0.windows.zip
[1] http://dlang.org/chagelog.html
[2] http://dlang.org/download.html
Regards,
Andrew
--
--------------------
http://www.akeron.co
auto getAddress() {
string location = " ", period = ".";
return ("info" ~ location ~ "afidem" ~ period ~ "org");
}
Feb 24 2014
On Monday, 24 February 2014 at 17:42:07 UTC, Manu wrote:Awesome! First thing I noticed though, the Windows installer seemed to forget where my existing D installation is, and tried to install it somewhere else. I thought this got fixed months ago? Regression in the installer?Nope, not a regression. That never got implemented.
Feb 24 2014
On 2/24/2014 9:48 AM, Brad Anderson wrote:On Monday, 24 February 2014 at 17:42:07 UTC, Manu wrote:Is there a bugzilla issue for this?First thing I noticed though, the Windows installer seemed to forget where my existing D installation is, and tried to install it somewhere else. I thought this got fixed months ago? Regression in the installer?Nope, not a regression. That never got implemented.
Feb 24 2014
On Monday, 24 February 2014 at 20:24:04 UTC, Walter Bright wrote:On 2/24/2014 9:48 AM, Brad Anderson wrote:Nope.On Monday, 24 February 2014 at 17:42:07 UTC, Manu wrote:Is there a bugzilla issue for this?First thing I noticed though, the Windows installer seemed to forget where my existing D installation is, and tried to install it somewhere else. I thought this got fixed months ago? Regression in the installer?Nope, not a regression. That never got implemented.
Feb 25 2014
On 2/25/2014 11:03 AM, Brad Anderson wrote:On Monday, 24 February 2014 at 20:24:04 UTC, Walter Bright wrote:Please make one - otherwise it'll get overlooked.On 2/24/2014 9:48 AM, Brad Anderson wrote:Nope.On Monday, 24 February 2014 at 17:42:07 UTC, Manu wrote:Is there a bugzilla issue for this?First thing I noticed though, the Windows installer seemed to forget where my existing D installation is, and tried to install it somewhere else. I thought this got fixed months ago? Regression in the installer?Nope, not a regression. That never got implemented.
Feb 25 2014
On Monday, 24 February 2014 at 08:45:31 UTC, Andrew Edwards wrote:The final release of DMD 2.065 is now available.Thanks for all your hard work, Andrew. Seems like Martin and Nick did a lot of work on the release infrastructure too so thanks to them as well and everyone else who worked on this release.
Feb 24 2014
El 24/02/14 09:45, Andrew Edwards ha escrit:The final release of DMD 2.065 is now available.Congratulations for this new dmd release! New deb packages and "dlangspec" in several formats available at <http://d-apt.sourceforge.net/> -- Jordi Sayol
Feb 24 2014
Looks like we need to do something about this: http://www.reddit.com/r/programming/comments/1ytfc5/d_2065_released_with_396_fixes_and_improvements/cfnmkih At a minimum, add it to the changelog. Or possibly remove that change.
Feb 24 2014
On Mon, 24 Feb 2014 15:29:51 -0500, Walter Bright <newshound2 digitalmars.com> wrote:Looks like we need to do something about this: http://www.reddit.com/r/programming/comments/1ytfc5/d_2065_released_with_396_fixes_and_improvements/cfnmkih At a minimum, add it to the changelog. Or possibly remove that change.I think the change should go (if it was intentional). IIRC, opCmp was required in D1 and older versions of D2, because hash collisions were stored in a tree instead of a LL. The documentation should be updated too. -Steve
Feb 24 2014
On Monday, 24 February 2014 at 21:00:53 UTC, Steven Schveighoffer wrote:I think the change should go (if it was intentional). IIRC, opCmp was required in D1 and older versions of D2, because hash collisions were stored in a tree instead of a LL. The documentation should be updated too. -SteveWhy *was* there a change to enforce that AA keys have opCmp? It doesn't seem to me like any responses SiegeLord got were satisfactory, i.e., why was this change made, and why was it not in the changelog?
Feb 24 2014
On Mon, 24 Feb 2014 16:09:39 -0500, Meta <jared771 gmail.com> wrote:On Monday, 24 February 2014 at 21:00:53 UTC, Steven Schveighoffer wrote:A wild wild guess is that there was code in the compiler that used to require it (after all, it was required a long time ago), and somehow it got reactivated by accident. But wild guesses don't help fix bugs :) In doing a search through my email of the dmd-internals mailing list, I don't see opCmp anywhere. -SteveI think the change should go (if it was intentional). IIRC, opCmp was required in D1 and older versions of D2, because hash collisions were stored in a tree instead of a LL. The documentation should be updated too. -SteveWhy *was* there a change to enforce that AA keys have opCmp? It doesn't seem to me like any responses SiegeLord got were satisfactory, i.e., why was this change made, and why was it not in the changelog?
Feb 24 2014
On Monday, 24 February 2014 at 21:22:12 UTC, Steven Schveighoffer wrote:A wild wild guess is that there was code in the compiler that used to require it (after all, it was required a long time ago), and somehow it got reactivated by accident. But wild guesses don't help fix bugs :) In doing a search through my email of the dmd-internals mailing list, I don't see opCmp anywhere. -SteveAh, I see. I got the impression that he thought it was a deliberate change, which is why he was so irate. Maybe someone should mention this in the thread.
Feb 24 2014
On Mon, 24 Feb 2014 16:23:45 -0500, Meta <jared771 gmail.com> wrote:Ah, I see. I got the impression that he thought it was a deliberate change, which is why he was so irate. Maybe someone should mention this in the thread.I did, but I have a feeling it won't help :) -Steve
Feb 24 2014
"Steven Schveighoffer" wrote in message news:op.xbs1naiueav7ka stevens-macbook-pro.local...A wild wild guess is that there was code in the compiler that used to require it (after all, it was required a long time ago), and somehow it got reactivated by accident. But wild guesses don't help fix bugs :)Walter + Andrei did it, and it was completely intentional, and it was known that it would break code. https://github.com/D-Programming-Language/dmd/pull/3054
Feb 25 2014
On Tuesday, 25 February 2014 at 10:28:41 UTC, Daniel Murphy wrote:Walter + Andrei did it, and it was completely intentional, and it was known that it would break code. https://github.com/D-Programming-Language/dmd/pull/3054I find it so ironical that Walter warns that this may break the code and few comments later says that more appropriate fix is not an option because "I don't want to break anything with this release" :P
Feb 25 2014
On Tue, 25 Feb 2014 05:28:42 -0500, Daniel Murphy <yebbliesnospam gmail.com> wrote:"Steven Schveighoffer" wrote in message news:op.xbs1naiueav7ka stevens-macbook-pro.local...This was the wrong fix. Druntime should be modified to use TypeInfo.equals instead of TypeInfo.compare. Compare is no longer needed, since it's only used to check for equality. Note that the docs say BOTH opEquals and opCmp should be specified, because either can be used. I would suggest a proper interim fix is to only reject key types that define opEquals, but not opCmp. Then switch to using equals in druntime. Finally, get rid of AA's as a specialized type, map them cleanly to a template. -SteveA wild wild guess is that there was code in the compiler that used to require it (after all, it was required a long time ago), and somehow it got reactivated by accident. But wild guesses don't help fix bugs :)Walter + Andrei did it, and it was completely intentional, and it was known that it would break code.
Feb 25 2014
On Tue, 25 Feb 2014 12:11:46 -0500, Steven Schveighoffer <schveiguy yahoo.com> wrote:I would suggest a proper interim fix is to only reject key types that define opEquals, but not opCmp. Then switch to using equals in druntime.Sorry, I meant define opCmp but not opEquals. Some types can be compared for equality but are not ordered (AA's for example!) -Steve
Feb 25 2014
On 2/25/2014 2:28 AM, Daniel Murphy wrote:Walter + Andrei did it, and it was completely intentional, and it was known that it would break code. https://github.com/D-Programming-Language/dmd/pull/3054It was intended to only break code that was already broken (would fail at runtime). It appears that this turned out to not be entirely true.
Feb 25 2014
On Tue, 25 Feb 2014 14:33:05 -0500, Walter Bright <newshound2 digitalmars.com> wrote:On 2/25/2014 2:28 AM, Daniel Murphy wrote:I just wrote this and compiled on 2.064: import std.stdio; struct S { int x; int y; bool opEquals(ref const(S) other) const { return other.x == x;} } void main() { int[S] aa; aa[S(1, 2)] = 5; aa[S(1, 3)] = 6; writeln(aa); } Output: [S(1, 2):5, S(1, 3):6] Now, clearly this is not correct, and should be flagged by the compiler, or fixed in the runtime. I suggest this path: 1. Switch AA to using the 'equals' function 2. Do not allow keys that provide opCmp function but not opEquals (these will not work correctly) This will provide a sane implementation and not break existing code when the default opEquals and opCmp are used (both will act the same as far as AAs are concerned). -SteveWalter + Andrei did it, and it was completely intentional, and it was known that it would break code. https://github.com/D-Programming-Language/dmd/pull/3054It was intended to only break code that was already broken (would fail at runtime). It appears that this turned out to not be entirely true.
Feb 25 2014
On 2014-02-25 20:49, Steven Schveighoffer wrote:
I just wrote this and compiled on 2.064:
import std.stdio;
struct S
{
int x;
int y;
bool opEquals(ref const(S) other) const { return other.x == x;}
}
void main()
{
int[S] aa;
aa[S(1, 2)] = 5;
aa[S(1, 3)] = 6;
writeln(aa);
}
Output:
[S(1, 2):5, S(1, 3):6]
Now, clearly this is not correct, and should be flagged by the compiler,
or fixed in the runtime.
I suggest this path:
1. Switch AA to using the 'equals' function
2. Do not allow keys that provide opCmp function but not opEquals (these
will not work correctly)
This will provide a sane implementation and not break existing code when
the default opEquals and opCmp are used (both will act the same as far
as AAs are concerned).
The thing is that the compiler complains about a deceleration looking
like this:
struct TagIndex
{
uint tag, index;
}
Neither opEquals or opCmp is overloaded. A simple test case will also
show that the compiler doesn't not complain about a missing opCmp. I
have not been able to create a reduced test case for this.
--
/Jacob Carlborg
Feb 25 2014
On Tue, 25 Feb 2014 15:12:41 -0500, Jacob Carlborg <doob me.com> wrote:The thing is that the compiler complains about a deceleration looking like this: struct TagIndex { uint tag, index; }If the compiler generates opEquals and opCmp, then it's guaranteed opEquals(x, y) is equivalent to opCmp(x, y) == 0. The compiler should NOT complain about this, which I should have more clearly stated (I thought I had).Neither opEquals or opCmp is overloaded. A simple test case will also show that the compiler doesn't not complain about a missing opCmp. I have not been able to create a reduced test case for this.I realized, after trying to get opCmp to work, I was missing a piece -- toHash! I couldn't get the thing to only store one key! So I have to update my requirements. Here are the two cases where a struct T should be usable as an AA key: 1. Neither opCmp nor opEquals are defined (and defaults are generated). 2. Both opEquals and toHash are defined. Any other key types should be disallowed. -Steve
Feb 25 2014
On 2014-02-25 22:51, Steven Schveighoffer wrote:If the compiler generates opEquals and opCmp, then it's guaranteed opEquals(x, y) is equivalent to opCmp(x, y) == 0. The compiler should NOT complain about this, which I should have more clearly stated (I thought I had).Filed as [1]. Unfortunately I wasn't able to find a reduced test case. [1] https://d.puremagic.com/issues/show_bug.cgi?id=12267 -- /Jacob Carlborg
Feb 26 2014
On 2014-02-24 21:29, Walter Bright wrote:Looks like we need to do something about this: http://www.reddit.com/r/programming/comments/1ytfc5/d_2065_released_with_396_fixes_and_improvements/cfnmkih At a minimum, add it to the changelog. Or possibly remove that change.I've been compiling Tango with the latest version for a couple of releases now. I found some issues for this release. Some were fixed. Some where code that should not have compiled previously. Then I hit the issue with opCmp and I failed to find a reduced test case. Why should I need opCmp in a struct containing only two ints? -- /Jacob Carlborg
Feb 25 2014
On 2014-02-24 21:29, Walter Bright wrote:Looks like we need to do something about this: http://www.reddit.com/r/programming/comments/1ytfc5/d_2065_released_with_396_fixes_and_improvements/cfnmkih At a minimum, add it to the changelog. Or possibly remove that change.Answering some of your comments here: Q: If the project fails to compile or run, who is responsible for debugging it A: Preferably we have some way to run a bunch of projects as part of the test suite. Developers sign up their projects if they want to participate. If a build fails the developer gets a notification. The developer is responsible for debugging. If a project has successfully passed the 10 latest releases but the 11th fails I think the DMD/Phobos developers could have a quick look to see if it's something obvious. Q: Individual projects tend to stick with particular subsets of the language. They may be large code bases, but likely exercise relatively small parts of the language, and so their successful compilation is not very indicative of much. A: That's not entirely true. I can tell you that DMD has broken DWT, one way or another, for, at least, the 10 latest releases. -- /Jacob Carlborg
Feb 25 2014
On 25 February 2014 17:30, Jacob Carlborg <doob me.com> wrote:On 2014-02-24 21:29, Walter Bright wrote:+1 I've have old projects break for silly reasons. A forward reference regression here, an ICE suddenly appeared there. These things happen and never get caught during the beta phase because. 1) I'm not actively developing the project. 2) I have a compiled binary I use sometimes day in day out, and have no reason to recompile it. :)Looks like we need to do something about this: http://www.reddit.com/r/programming/comments/1ytfc5/d_2065_released_with_396_fixes_and_improvements/cfnmkih At a minimum, add it to the changelog. Or possibly remove that change.Answering some of your comments here: Q: If the project fails to compile or run, who is responsible for debugging it A: Preferably we have some way to run a bunch of projects as part of the test suite. Developers sign up their projects if they want to participate. If a build fails the developer gets a notification. The developer is responsible for debugging. If a project has successfully passed the 10 latest releases but the 11th fails I think the DMD/Phobos developers could have a quick look to see if it's something obvious. Q: Individual projects tend to stick with particular subsets of the language. They may be large code bases, but likely exercise relatively small parts of the language, and so their successful compilation is not very indicative of much. A: That's not entirely true. I can tell you that DMD has broken DWT, one way or another, for, at least, the 10 latest releases.
Feb 25 2014
On 2/24/2014 12:29 PM, Walter Bright wrote:Looks like we need to do something about this: http://www.reddit.com/r/programming/comments/1ytfc5/d_2065_released_with_396_fixes_and_improvements/cfnmkih At a minimum, add it to the changelog. Or possibly remove that change.https://d.puremagic.com/issues/show_bug.cgi?id=12255
Feb 25 2014
BTW it seems the copyright notice is outdated:
DMD64 D Compiler v2.065
Copyright (c) *1999-2013* by Digital Mars written by Walter Bright
Documentation: http://dlang.org/
On Mon, Feb 24, 2014 at 10:45 AM, Andrew Edwards <ridimz yahoo.com> wrote:
The final release of DMD 2.065 is now available. [1] contains complete
descriptions of all changes, enhancements and fixes for this release.
Available binaries can be accessed at [2]. Since the website will lag
slightly behind, links are provided below for convenience.
All Systems:
http://ftp.digitalmars.com/dmd.2.065.0.zip
FreeBSD:
http://ftp.digitalmars.com/dmd.2.065.0.freebsd-64.zip
http://ftp.digitalmars.com/dmd.2.065.0.freebsd-32.zip
Linux:
http://ftp.digitalmars.com/dmd_2.065.0-0_i386.deb
http://ftp.digitalmars.com/dmd_2.065.0-0_amd64.deb
http://ftp.digitalmars.com/dmd-2.065.0-0.fedora.i386.rpm
http://ftp.digitalmars.com/dmd-2.065.0-0.fedora.x86_64.rpm
http://ftp.digitalmars.com/dmd-2.065.0-0.openSUSE.i386.rpm
http://ftp.digitalmars.com/dmd-2.065.0-0.openSUSE.x86_64.rpm
http://ftp.digitalmars.com/dmd.2.065.0.linux.zip
MAC OS X:
http://ftp.digitalmars.com/dmd.2.065.0.dmg
http://ftp.digitalmars.com/dmd.2.065.0.osx.zip
Windows:
http://ftp.digitalmars.com/dmd-2.065.0.exe
http://ftp.digitalmars.com/dmd.2.065.0.windows.zip
[1] http://dlang.org/chagelog.html
[2] http://dlang.org/download.html
Regards,
Andrew
--
--------------------
http://www.akeron.co
auto getAddress() {
string location = " ", period = ".";
return ("info" ~ location ~ "afidem" ~ period ~ "org");
}
Feb 24 2014
Great work! It warms my heart to see D improving at a steady rate. I'm starting to use it on my next major project as it also seems the IDE support (Mono-D) has improved too.
Feb 24 2014
On 2/24/2014 12:45 AM, Andrew Edwards wrote:The final release of DMD 2.065 is now available. [1] contains complete descriptions of all changes, enhancements and fixes for this release.Thank you, everyone, for this release! And a special thanks to Andrew who stepped up to organize and manage the release process.
Feb 24 2014
On Monday, 24 February 2014 at 08:45:31 UTC, Andrew Edwards wrote:The final release of DMD 2.065 is now available. [1] contains complete descriptions of all changes, enhancements and fixes for this release.Nice job wrangling the new release schedule and shepherding your first release out the door, hopefully the first of many to come. Hope it's not too much more work than you thought it'd be when I recommended that you talk to the core devs about taking on the position. Also, kudos to all the contributors, nice to see an amd64 build for FreeBSD finally.
Feb 25 2014
24-Feb-2014 12:45, Andrew Edwards пишет:The final release of DMD 2.065 is now available. [1] contains complete descriptions of all changes, enhancements and fixes for this release. Available binaries can be accessed at [2]. Since the website will lag slightly behind, links are provided below for convenience.Awesome. Thanks to everybody behind the release engineering. I don't know how good or painful it gets for these involved but from the outside (as a core developer) I see remarkable progress in handling the process. -- Dmitry Olshansky
Feb 25 2014
On Monday, 24 February 2014 at 08:45:31 UTC, Andrew Edwards wrote:The final release of DMD 2.065 is now available. [1] contains complete descriptions of all changes, enhancements and fixes for this release.I am having an issue with the windows installer : http://puu.sh/7NdXY.png The URL he is trying to use to download dmd.2.065.zip is broken : http://downloads.dlang.org/releases/2013/dmd.2.065.0.zip instead of : http://downloads.dlang.org/releases/2014/dmd.2.065.0.zip I have downloaded it from the dlang.org download page. I can't believe this was not noticed before, did the installer has been rebuilt recently ? This is very odd as the "2014" string is correctly hardcoded in the sourcecode : https://github.com/D-Programming-Language/installer/blob/master/windows/dinstaller.nsi#L32 Is it related to my version of Windows ( 8 64bits ) ?
Mar 28 2014
On Friday, 28 March 2014 at 22:50:32 UTC, Théo Bueno wrote:I am having an issue with the windows installer :Ok, so after investigations I partially fixed my problem : - I have no idea why the installer tried to download with the wrong URL, this should not happen, and on my own compiled version of the installer this did not happen. - The plugin used by NSIS to download files, inetc, depends on WinetAPI, which means that if your Internet Explorer installation is not working ( that was my case ), the installer can't work. - The installer code is very old, and we should think about updating it ( replace the obsolete "nsisunz" plugin by "ZipDLL", avoid "inetc" problems using builtin "NSISdl" ... )
Mar 29 2014
On Saturday, 29 March 2014 at 13:25:19 UTC, Théo Bueno wrote:On Friday, 28 March 2014 at 22:50:32 UTC, Théo Bueno wrote:The current plan (by me at least) is to just do away with the downloading entirely and just embedding the files in the installer.I am having an issue with the windows installer :Ok, so after investigations I partially fixed my problem : - I have no idea why the installer tried to download with the wrong URL, this should not happen, and on my own compiled version of the installer this did not happen. - The plugin used by NSIS to download files, inetc, depends on WinetAPI, which means that if your Internet Explorer installation is not working ( that was my case ), the installer can't work. - The installer code is very old, and we should think about updating it ( replace the obsolete "nsisunz" plugin by "ZipDLL", avoid "inetc" problems using builtin "NSISdl" ... )
Apr 01 2014
On Tuesday, 1 April 2014 at 19:03:10 UTC, Brad Anderson wrote:On Saturday, 29 March 2014 at 13:25:19 UTC, Théo Bueno wrote:Would be the best indeed. An online installer is not useful in our case as all the installers and packages are automagically built.On Friday, 28 March 2014 at 22:50:32 UTC, Théo Bueno wrote:The current plan (by me at least) is to just do away with the downloading entirely and just embedding the files in the installer.I am having an issue with the windows installer :Ok, so after investigations I partially fixed my problem : - I have no idea why the installer tried to download with the wrong URL, this should not happen, and on my own compiled version of the installer this did not happen. - The plugin used by NSIS to download files, inetc, depends on WinetAPI, which means that if your Internet Explorer installation is not working ( that was my case ), the installer can't work. - The installer code is very old, and we should think about updating it ( replace the obsolete "nsisunz" plugin by "ZipDLL", avoid "inetc" problems using builtin "NSISdl" ... )
Apr 02 2014