Re: dmd 2.065.0

2014-04-02 Thread Théo.Bueno

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:

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


The current plan (by me at least) is to just do away with the 
downloading entirely and just embedding the files in the 
installer.


Would be the best indeed. An online installer is not useful in 
our case as all the installers and packages are automagically 
built.




Re: dmd 2.065.0

2014-04-01 Thread Brad Anderson

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:

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


The current plan (by me at least) is to just do away with the 
downloading entirely and just embedding the files in the 
installer.


Re: dmd 2.065.0

2014-03-29 Thread Théo.Bueno

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


Re: dmd 2.065.0

2014-03-28 Thread Théo.Bueno

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



Re: dmd 2.065.0

2014-02-26 Thread Jacob Carlborg

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


Re: dmd 2.065.0

2014-02-25 Thread Daniel Murphy
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 



Re: dmd 2.065.0

2014-02-25 Thread Dicebot

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/3054


I 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


Re: dmd 2.065.0

2014-02-25 Thread Steven Schveighoffer
On Tue, 25 Feb 2014 05:28:42 -0500, Daniel Murphy  
yebbliesnos...@gmail.com wrote:


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.


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.


-Steve


Re: dmd 2.065.0

2014-02-25 Thread Jacob Carlborg

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


Re: dmd 2.065.0

2014-02-25 Thread Joakim

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.


Re: dmd 2.065.0

2014-02-25 Thread Jacob Carlborg

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


Re: dmd 2.065.0

2014-02-25 Thread Steven Schveighoffer
On Tue, 25 Feb 2014 12:11:46 -0500, Steven Schveighoffer  
schvei...@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


Re: dmd 2.065.0

2014-02-25 Thread Brad Anderson

On Monday, 24 February 2014 at 20:24:04 UTC, Walter Bright wrote:

On 2/24/2014 9:48 AM, Brad Anderson wrote:

On Monday, 24 February 2014 at 17:42:07 UTC, Manu wrote:
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.


Is there a bugzilla issue for this?


Nope.


Re: dmd 2.065.0

2014-02-25 Thread Walter Bright

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/3054


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


Re: dmd 2.065.0

2014-02-25 Thread Walter Bright

On 2/25/2014 11:03 AM, Brad Anderson wrote:

On Monday, 24 February 2014 at 20:24:04 UTC, Walter Bright wrote:

On 2/24/2014 9:48 AM, Brad Anderson wrote:

On Monday, 24 February 2014 at 17:42:07 UTC, Manu wrote:

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.


Is there a bugzilla issue for this?


Nope.


Please make one - otherwise it'll get overlooked.


Re: dmd 2.065.0

2014-02-25 Thread Iain Buclaw
On 25 February 2014 17:30, Jacob Carlborg d...@me.com wrote:
 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.


+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.   :)


Re: dmd 2.065.0

2014-02-25 Thread Walter Bright

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


Re: dmd 2.065.0

2014-02-25 Thread Dmitry Olshansky

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


Re: dmd 2.065.0

2014-02-25 Thread Steven Schveighoffer
On Tue, 25 Feb 2014 14:33:05 -0500, Walter Bright  
newshou...@digitalmars.com wrote:



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/3054


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


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


-Steve


Re: dmd 2.065.0

2014-02-25 Thread Jacob Carlborg

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


Re: dmd 2.065.0

2014-02-25 Thread Steven Schveighoffer

On Tue, 25 Feb 2014 15:12:41 -0500, Jacob Carlborg d...@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


dmd 2.065.0

2014-02-24 Thread 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.


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);
}


Re: dmd 2.065.0

2014-02-24 Thread simendsjo

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


Great news! Your changelog link has a typo, and it's not updated for 2.065.


Re: dmd 2.065.0

2014-02-24 Thread Kelet
\o/ Congrats! I'm excited for this release, it fixes a good 
amount of bugs that have been plaguing me.


Re: dmd 2.065.0

2014-02-24 Thread extrawurst

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


Re: dmd 2.065.0

2014-02-24 Thread Szymon Gatner

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.


Re: dmd 2.065.0

2014-02-24 Thread Andrew Edwards

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


Correction: http://dlang.org/changelog.html

Note that this page is still pinging update to 2.065.


Re: dmd 2.065.0

2014-02-24 Thread Francesco Cattoglio

On Monday, 24 February 2014 at 10:33:27 UTC, Szymon Gatner wrote:



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


Re: dmd 2.065.0

2014-02-24 Thread Szymon Gatner
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:




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


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?




Re: dmd 2.065.0

2014-02-24 Thread Kapps

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


Re: dmd 2.065.0

2014-02-24 Thread Szymon Gatner

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


Clear, thanks. 2.066 then I suppose?


Re: dmd 2.065.0

2014-02-24 Thread Szymon Gatner

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


Clear, thanks. 2.066 then I suppose?


Re: dmd 2.065.0

2014-02-24 Thread Namespace

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


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.


Re: dmd 2.065.0

2014-02-24 Thread Szymon Gatner

On Monday, 24 February 2014 at 11:45:20 UTC, Namespace wrote:

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


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.


Yes yes, I understand :)


Re: dmd 2.065.0

2014-02-24 Thread Namespace

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


Clear, thanks. 2.066 then I suppose?


Let us hope so!


Re: dmd 2.065.0

2014-02-24 Thread Francesco Cattoglio

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


Re: dmd 2.065.0

2014-02-24 Thread Tourist

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


The .zip file for Windows isn't listed on the download page.
http://dlang.org/download.html


Re: dmd 2.065.0

2014-02-24 Thread Dominikus Dittes Scherkl

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.


Re: dmd 2.065.0

2014-02-24 Thread Jordi Sayol
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


Re: dmd 2.065.0

2014-02-24 Thread Andrei Alexandrescu

On 2/24/14, 4:24 AM, Francesco Cattoglio wrote:

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?


Not finally... virtually :o).

Andrei



Re: dmd 2.065.0

2014-02-24 Thread Mike

On Monday, 24 February 2014 at 17:37:08 UTC, Dicebot wrote:

Arch packages have just been updated.


Thank You!

Mike


Re: dmd 2.065.0

2014-02-24 Thread Walter Bright

On 2/24/2014 9:48 AM, Brad Anderson wrote:

On Monday, 24 February 2014 at 17:42:07 UTC, Manu wrote:

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.


Is there a bugzilla issue for this?


Re: dmd 2.065.0

2014-02-24 Thread Walter Bright

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.


Re: dmd 2.065.0

2014-02-24 Thread Rory McGuire
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 rid...@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);
 }



Re: dmd 2.065.0

2014-02-24 Thread Jonathan Dunlap
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.


Re: dmd 2.065.0

2014-02-24 Thread Steven Schveighoffer
On Mon, 24 Feb 2014 15:29:51 -0500, Walter Bright  
newshou...@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


Re: dmd 2.065.0

2014-02-24 Thread Meta
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.

-Steve


Why *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?


Re: dmd 2.065.0

2014-02-24 Thread Walter Bright

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.




Re: dmd 2.065.0

2014-02-24 Thread Meta
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.


-Steve


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.


Re: dmd 2.065.0

2014-02-24 Thread Steven Schveighoffer

On Mon, 24 Feb 2014 16:09:39 -0500, Meta jared...@gmail.com wrote:


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.

-Steve


Why *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?


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.


-Steve


Re: dmd 2.065.0

2014-02-24 Thread Steven Schveighoffer

On Mon, 24 Feb 2014 16:23:45 -0500, Meta jared...@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


Re: dmd 2.065.0

2014-02-24 Thread Joseph Cassman
On Monday, 24 February 2014 at 18:58:50 UTC, Andrei Alexandrescu 
wrote:

On 2/24/14, 4:24 AM, Francesco Cattoglio wrote:

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?


Not finally... virtually :o).

Andrei


Not bad. :-)

Joseph


Re: dmd 2.065.0

2014-02-24 Thread Leandro Lucarella
Szymon Gatner, el 24 de February a las 11:48 me escribiste:
 On Monday, 24 February 2014 at 11:45:20 UTC, Namespace wrote:
 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:
 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
 
 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, 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 ah!
But you may feel a little sick.


Re: dmd 2.065.0

2014-02-24 Thread Namespace
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:

On Monday, 24 February 2014 at 11:45:20 UTC, Namespace wrote:
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:
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

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, what? That was one of C++ biggest mistakes! You are 
seriously

wanting to do that?


Don't worry:
https://d.puremagic.com/issues/show_bug.cgi?id=11616#c3