November 06, 2013
On Wednesday, 6 November 2013 at 19:57:40 UTC, Walter Bright wrote:
> On 11/6/2013 4:34 AM, Leandro Lucarella wrote:
>> Also I find strange that the first patchlevel version is 2 and not 1.
>> Was that intended or just an error?
>
> It was intended. I felt that 2.064 => 2.064.1 would have been confusing, hence 2.064 => 2.064.2

But were there 2.064 and 2.064.1 releases? If I'm not mistaken the last release was 2.063.2 (at least judging by the website), next major release should be 2.064, not 2.064.1 or 2.064.2 (those are patch releases, not major ones).

If 2.064.1 was a RC then it was badly named. As IMHO RC versions must be marked with rc, as betas are marked with b "flag". Something like 2.064-rc.1, 2.064-rc.2, ... 2.064 (stable/major release), 2.064.1 (patch release), ...

This (-rc.xx) is how RC versions should be marked as per SEMVER "standard" (http://semver.org), although I know that D doesn't follow semantic versioning as defined in that standard.


Other than this thing with versioning I must say that I'm very pleased with changes in this version, so congrats to all people involved! :)
November 06, 2013
On Wednesday, 6 November 2013 at 20:06:54 UTC, Andrei Alexandrescu wrote:
> On 11/6/13 11:56 AM, Walter Bright wrote:
>> It might. You can confirm by seeing if it works with -allinst switch.
>
> I confirm it works when compiled with -allinst.

Is that switch new? It is not documented in the changelog.
November 06, 2013
On Tue, 05 Nov 2013 14:08:50 -0800, Walter Bright wrote:

> Ok, this is it:
> 
> http://ftp.digitalmars.com/dmd_2.064.2-0_amd64.deb http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd_2.064.2-0_i386.deb http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd-2.064.2.exe http://ftp.digitalmars.com/dmd.2.064.2.zip http://ftp.digitalmars.com/dmd.2.064.2.dmg http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_amd64.deb http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_i386.deb

First, I would like to thank everyone who has put hard work into the latest release and am really excited about the enhancements and fixed bugs.

Second, I agree with others that this should have been 2.064, not 2.064.2. This is an initial release not a patch/minor release.

Third, the fix for the issue at https://d.puremagic.com/issues/ show_bug.cgi?id=10690 was not included in the release and is a blocking bug for my company's code base. Till there is a new release with that fix included, we will not be able to use 2.064.

Many thanks again for a great programming language, Jonathan from EMSI
November 06, 2013
On Wed, 06 Nov 2013 20:27:01 +0000, Jonathan Crapuchettes wrote:

> On Tue, 05 Nov 2013 14:08:50 -0800, Walter Bright wrote:
> 
>> Ok, this is it:
>> 
>> http://ftp.digitalmars.com/dmd_2.064.2-0_amd64.deb http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd_2.064.2-0_i386.deb http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd-2.064.2.exe http://ftp.digitalmars.com/dmd.2.064.2.zip http://ftp.digitalmars.com/dmd.2.064.2.dmg http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_amd64.deb http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_i386.deb
> 
> First, I would like to thank everyone who has put hard work into the latest release and am really excited about the enhancements and fixed bugs.
> 
> Second, I agree with others that this should have been 2.064, not 2.064.2. This is an initial release not a patch/minor release.
> 
> Third, the fix for the issue at https://d.puremagic.com/issues/ show_bug.cgi?id=10690 was not included in the release and is a blocking bug for my company's code base. Till there is a new release with that fix included, we will not be able to use 2.064.
> 
> Many thanks again for a great programming language, Jonathan from EMSI

I just double checked the code in issue 10690 and it works just fine. I had assumed that my code was similar enough to not have been worth an additional bug report. I was wrong. I'll log a bug report and try to work around the assertion failure in std.algorithm.

Thanks again,
Jonathan
November 06, 2013
On Wed, 06 Nov 2013 20:37:56 +0000, Jonathan Crapuchettes wrote:

> On Wed, 06 Nov 2013 20:27:01 +0000, Jonathan Crapuchettes wrote:
> 
>> On Tue, 05 Nov 2013 14:08:50 -0800, Walter Bright wrote:
>> 
>>> Ok, this is it:
>>> 
>>> http://ftp.digitalmars.com/dmd_2.064.2-0_amd64.deb http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd_2.064.2-0_i386.deb http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd-2.064.2.exe http://ftp.digitalmars.com/dmd.2.064.2.zip http://ftp.digitalmars.com/dmd.2.064.2.dmg http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_amd64.deb http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_i386.deb
>> 
>> First, I would like to thank everyone who has put hard work into the latest release and am really excited about the enhancements and fixed bugs.
>> 
>> Second, I agree with others that this should have been 2.064, not 2.064.2. This is an initial release not a patch/minor release.
>> 
>> Third, the fix for the issue at https://d.puremagic.com/issues/ show_bug.cgi?id=10690 was not included in the release and is a blocking bug for my company's code base. Till there is a new release with that fix included, we will not be able to use 2.064.
>> 
>> Many thanks again for a great programming language, Jonathan from EMSI
> 
> I just double checked the code in issue 10690 and it works just fine. I had assumed that my code was similar enough to not have been worth an additional bug report. I was wrong. I'll log a bug report and try to work around the assertion failure in std.algorithm.
> 
> Thanks again,
> Jonathan

Disregard the last post. The issue still exists; I was just looking at the wrong file.
November 06, 2013
Is it possible to build something like wrap, so that it can be given a wrapping class instead of a wrapping interface?

I was trying to build something very similar to wrap, and at first glance it seems like wrap might suit me, except that I wanted to wrap the wolf in the "class Sheep"s clothes, not in an ISheep.

(typecons.d(2864): Error: class std.typecons.wrap!(B).wrap!(A).Impl base type must be interface, not main.B)
November 06, 2013
On Wednesday, 6 November 2013 at 20:11:13 UTC, Aleksandar Ruzicic wrote:
> versions must be marked with rc, as betas are marked with b "flag". Something like 2.064-rc.1, 2.064-rc.2, ... 2.064 (stable/major release), 2.064.1 (patch release), ...
>
> This (-rc.xx) is how RC versions should be marked as per SEMVER "standard" (http://semver.org), although I know that D doesn't follow semantic versioning as defined in that standard.

The D version numbers fail requirement 2 of semantic versioning:

2. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes.

I know that was discussed somewhere, but I don't know/recall why there is a leading zero in the minor version number.
November 06, 2013
On 2013-11-06 20:57, Walter Bright wrote:

> It was intended. I felt that 2.064 => 2.064.1 would have been confusing,
> hence 2.064 => 2.064.2

That's what's happening if you start to add new digits. The first release should have possibly been 2.064.0. BTW, there was a 2.063.1, if I recall correctly.

-- 
/Jacob Carlborg
November 06, 2013
On Wednesday, 6 November 2013 at 20:46:23 UTC, Luís Marques wrote:
> Is it possible to build something like wrap, so that it can be given a wrapping class instead of a wrapping interface?
>
> I was trying to build something very similar to wrap, and at first glance it seems like wrap might suit me, except that I wanted to wrap the wolf in the "class Sheep"s clothes, not in an ISheep.
>
> (typecons.d(2864): Error: class std.typecons.wrap!(B).wrap!(A).Impl base type must be interface, not main.B)

classes have implementations and state you need to initialize. It's possible to implement that in wrap but more problematic.
November 06, 2013
On Tuesday, 5 November 2013 at 22:08:48 UTC, Walter Bright wrote:
> Ok, this is it:
>
> http://ftp.digitalmars.com/dmd_2.064.2-0_amd64.deb
> http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.i386.rpm
> http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.x86_64.rpm
> http://ftp.digitalmars.com/dmd_2.064.2-0_i386.deb
> http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.i386.rpm
> http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.x86_64.rpm
> http://ftp.digitalmars.com/dmd-2.064.2.exe
> http://ftp.digitalmars.com/dmd.2.064.2.zip
> http://ftp.digitalmars.com/dmd.2.064.2.dmg
> http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_amd64.deb
> http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_i386.deb

Good job everyone!
DPaste is already using it