www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD v2.066.0-b2

reply Andrew Edwards <ridimz yahoo.com> writes:
The v2.066.0-b2 binaries are now available. The review period will run until
0700 UTC (0000 PDT) 14 July 2014. Your assistance in identifying and reporting
bugs are
greatly appreciated.

Binaries are located here:

	ALL
	ftp://ftp.digitalmars.com/dmd.2.066.0-b2.zip

	OSX
	ftp://ftp.digitalmars.com/dmd.2.066.0-b2.dmg
	ftp://ftp.digitalmars.com/dmd.2.066.0-b2.osx.zip

	FREEBSD
	ftp://ftp.digitalmars.com/dmd.2.066.0-b2.freebsd-32.zip
	ftp://ftp.digitalmars.com/dmd.2.066.0-b2.freebsd-64.zip

	LINUX
	ftp://ftp.digitalmars.com/dmd_2.066.0~b2-0_i386.deb
	ftp://ftp.digitalmars.com/dmd_2.066.0~b2-0_amd64.deb
	ftp://ftp.digitalmars.com/dmd.2.066.0-b2.linux.zip
	ftp://ftp.digitalmars.com/dmd-2.066.0~b2-0.openSUSE.i386.rpm
	ftp://ftp.digitalmars.com/dmd-2.066.0~b2-0.openSUSE.x86_64.rpm
	ftp://ftp.digitalmars.com/dmd-2.066.0~b2-0.fedora.i386.rpm
	ftp://ftp.digitalmars.com/dmd-2.066.0~b2-0.fedora.x86_64.rpm
	ftp://ftp.digitalmars.com/libphobos2-66_2.066.0~b2-0_i386.deb
	ftp://ftp.digitalmars.com/libphobos2-66_2.066.0~b2-0_amd64.deb

	WINDOWS
	ftp://ftp.digitalmars.com/dmd.2.066.0-b2.windows.zip
	ftp://ftp.digitalmars.com/dmd-2.066.0-b2.exe

Request assistance in identifying non-breaking changes (fixes) for
inclusion in the 2.065.1 point release. I need assistance with this
because I do not have the expertise to determine what goes into the
point release. If nothing is identified, I will abandon the idea of
providing point releases.

A issues ([1] & [2]) have been created for identifying commits that
require cherry picking for inclusion in future beta/release candidates.
Commits not identified will not be picked.

Enjoy,
Andrew

[1] [Cherry-pick v2.066.0-b3]https://issues.dlang.org/show_bug.cgi?id=13072 
<https://issues.dlang.org/show_bug.cgi?id=13035>
[2] [Cherry-pick v2.065.1-b1]https://issues.dlang.org/show_bug.cgi?id=13036
Jul 08 2014
next sibling parent reply "kdmult" <kdmult ya.ru> writes:
The download links are broken. They should have prefix http:// 
instead of ftp://.
Jul 08 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 8 July 2014 at 13:48:45 UTC, kdmult wrote:

 The download links are broken. They should have prefix http:// 
 instead of ftp://.


Hmm... they work for me.
Jul 08 2014
parent reply "NCrashed . via Digitalmars-d-announce" writes:
Also the link on main page is broken.


2014-07-08 18:10 GMT+04:00 via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com>:


 On Tuesday, 8 July 2014 at 13:48:45 UTC, kdmult wrote:


 The download links are broken. They should have prefix http:// instead
 of ftp://.


 Hmm... they work for me.
Jul 08 2014
parent Andrew Edwards <ridimz yahoo.com> writes:
On 7/8/14, 11:16 PM, NCrashed . via Digitalmars-d-announce wrote:

 Also the link on main page is broken.


https://issues.dlang.org/show_bug.cgi?id=13080
Jul 08 2014
prev sibling next sibling parent reply "John" <john.joyus gmail.com> writes:
On Tuesday, 8 July 2014 at 10:38:52 UTC, Andrew Edwards wrote:

 If nothing is identified, I will abandon the idea of providing 
 point releases.


Managing multiple Alpha or Beta builds with a1, a2 .. or b1, b2 
etc look good.

Adding another point-number to the 2.066 like 2.066.1 is a 
needless confusion, unless you have already released 2.066 and 
coming up with an intermediate release before 2.067
Jul 08 2014
parent Andrew Edwards <ridimz yahoo.com> writes:
On 7/8/14, 11:39 PM, John wrote:

 On Tuesday, 8 July 2014 at 10:38:52 UTC, Andrew Edwards wrote:

 If nothing is identified, I will abandon the idea of providing point
 releases.


 Managing multiple Alpha or Beta builds with a1, a2 .. or b1, b2 etc look
 good.

 Adding another point-number to the 2.066 like 2.066.1 is a needless
 confusion, unless you have already released 2.066 and coming up with an
 intermediate release before 2.067


Note that the maintenance/point release refers specifically to 2.065.1. 
2.065 was released in February and there is nothing that says you cannot 
continue maintaining it after we've released 2.066.
Jul 08 2014
prev sibling parent reply "NCrashed" <NCrashed gmail.com> writes:
On Tuesday, 8 July 2014 at 10:38:52 UTC, Andrew Edwards wrote:

 The v2.066.0-b2 binaries are now available. The review period 
 will run until 0700 UTC (0000 PDT) 14 July 2014. Your 
 assistance in identifying and reporting bugs are
 greatly appreciated.


Link to this post on dlang.org main page is broken.
Jul 08 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 7/8/14, 11:47 PM, NCrashed wrote:

 On Tuesday, 8 July 2014 at 10:38:52 UTC, Andrew Edwards wrote:

 The v2.066.0-b2 binaries are now available. The review period will run
 until 0700 UTC (0000 PDT) 14 July 2014. Your assistance in identifying
 and reporting bugs are
 greatly appreciated.


 Link to this post on dlang.org main page is broken.


https://issues.dlang.org/show_bug.cgi?id=13080
Jul 08 2014
parent reply "Bob" <trash trashmail.com> writes:
Hi, I hit problem with templates/opDispatch.

http://pastebin.com/rc09yWNt

% uname -a

UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Jul 09 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 7/9/14, 4:18 PM, Bob wrote:

 Hi, I hit problem with templates/opDispatch.

 http://pastebin.com/rc09yWNt

 % uname -a

 2014 x86_64 x86_64 x86_64 GNU/Linux


What does this event mean? Where does xyz come from? The code below also 
compiles in 2.065.0 on osx, but comment out opDispach() and it fails 
with the same error message as above.

Seems to be a bug that got fixed.

void main() {
     auto e = Vec4(5, 3, 3, 1);

     // This worked with dmd_2.065.0-0_amd64
     // but does not work with dmd_2.066.0~b2-0_amd64
     auto x = e.xyz; // Error: no property 'xyz' for type 'Vec!4'
}

alias Vec4 = Vec!4;

struct Vec(int dim) {

     union {
         struct {
             float h;
             float i;
             float j;
             static if (4 <= dim) float w;
         }
     }

     this(float h, float i, float j, float w) {}

     auto opDispatch(string components)() const {
         Vec!(1) result = void;
         return result;
     }
}
Jul 09 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 7/9/14, 5:58 PM, Andrew Edwards wrote:

 On 7/9/14, 4:18 PM, Bob wrote:

 Hi, I hit problem with templates/opDispatch.

 http://pastebin.com/rc09yWNt

 % uname -a

 2014 x86_64 x86_64 x86_64 GNU/Linux


 What does this event mean? Where does xyz come from? The code below also
 compiles in 2.065.0 on osx, but comment out opDispach() and it fails
 with the same error message as above.

 Seems to be a bug that got fixed.


This works in 2.065.0 also:

void main() {
     auto e = Vec4(5);

     // This worked with dmd_2.065.0-0_amd64
     // but does not work with dmd_2.066.0~b2-0_amd64
     auto x = e.xyz; // Error: no property 'xyz' for type 'Vec!4'
}

alias Vec4 = Vec!4;

struct Vec(int dim) {

     this(float h) {}

     auto opDispatch(string components)() {
         Vec!(1) result = void;
         return result;
     }
}

remove the "string components" parameter form opDispatch to reveal the 
same error.
Jul 09 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 9 July 2014 at 12:11:13 UTC, Andrew Edwards wrote:

 remove the "string components" parameter form opDispatch to 
 reveal the same error.


Hm, could you elaborate a bit further on this? As per the spec, 
opDispatch requires a string parameter 
(http://dlang.org/operatoroverloading.html#Dispatch). Removing it 
means that the compiler no longer considers the template to match 
the opDispatch signature, and thus of course .xyz fails.

David
Jul 09 2014
parent reply "Andrew Edwards" <ridimz yahoo.com> writes:
On Wednesday, 9 July 2014 at 12:21:20 UTC, David Nadlinger wrote:

 On Wednesday, 9 July 2014 at 12:11:13 UTC, Andrew Edwards wrote:

 remove the "string components" parameter form opDispatch to 
 reveal the same error.


 Hm, could you elaborate a bit further on this? As per the spec, 
 opDispatch requires a string parameter 
 (http://dlang.org/operatoroverloading.html#Dispatch). Removing 
 it means that the compiler no longer considers the template to 
 match the opDispatch signature, and thus of course .xyz fails.

 David


My concern is that this shouldn't compile in the first place. 
What is xyz?, Is it a free function? Is it a member variable or 
function?  In my mind it is neither of the two so why does it 
compile? Removing the string changes the signature of opDispatch 
but as shown in my prior example, there are orther ways to cause 
this error.
Jul 09 2014
next sibling parent Ben Boeckel via Digitalmars-d-announce writes:
On Wed, Jul 09, 2014 at 14:56:59 +0000, Andrew Edwards via
Digitalmars-d-announce wrote:

 My concern is that this shouldn't compile in the first place. What is
 xyz?, Is it a free function? Is it a member variable or function?  In
 my mind it is neither of the two so why does it compile? Removing the
 string changes the signature of opDispatch but as shown in my prior
 example, there are orther ways to cause this error.


It's swizzling. gl3n[1] implements it as well.

--Ben

[1]https://github.com/Dav1dde/gl3n/blob/master/gl3n/linalg.d#L375
Jul 09 2014
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 9 July 2014 at 14:57:01 UTC, Andrew Edwards wrote:

 My concern is that this shouldn't compile in the first place. 
 What is xyz?, Is it a free function? Is it a member variable or 
 function?  In my mind it is neither of the two so why does it 
 compile?


Oh, but that's precisely the point of opDispatch. ;) It offers a 
mechanism to respond to any members that are not found. See the 
spec for an example: 
http://dlang.org/operatoroverloading.html#Dispatch

David
Jul 09 2014
parent reply "Bob" <noone stillnoemail.net> writes:
On Wednesday, 9 July 2014 at 15:39:50 UTC, David Nadlinger wrote:

 On Wednesday, 9 July 2014 at 14:57:01 UTC, Andrew Edwards wrote:

 My concern is that this shouldn't compile in the first place. 
 What is xyz?, Is it a free function? Is it a member variable 
 or function?  In my mind it is neither of the two so why does 
 it compile?


 Oh, but that's precisely the point of opDispatch. ;) It offers 
 a mechanism to respond to any members that are not found. See 
 the spec for an example: 
 http://dlang.org/operatoroverloading.html#Dispatch

 David


Exactly. opDispatch catches calls to missing methods and acts 
based on method name which it gets as a string at compile time. 
In this case, the idea is this:

         auto v1 = Vec!4(4, 5, 6, 7);
         auto v2 = v1.xyz;   // => Vec!3(4, 5, 6);
         auto v3 = v1.wx;    // => Vec!2(7, 4);
         auto v4 = v1.wxx1;  // => Vec!4(7, 4, 4, 1);
Jul 09 2014
parent Andrew Edwards <ridimz yahoo.com> writes:
On 7/10/14, 2:35 AM, Bob wrote:

 On Wednesday, 9 July 2014 at 15:39:50 UTC, David Nadlinger wrote:

 On Wednesday, 9 July 2014 at 14:57:01 UTC, Andrew Edwards wrote:

 My concern is that this shouldn't compile in the first place. What is
 xyz?, Is it a free function? Is it a member variable or function?  In
 my mind it is neither of the two so why does it compile?


 Oh, but that's precisely the point of opDispatch. ;) It offers a
 mechanism to respond to any members that are not found. See the spec
 for an example: http://dlang.org/operatoroverloading.html#Dispatch

 David


 Exactly. opDispatch catches calls to missing methods and acts based on
 method name which it gets as a string at compile time. In this case, the
 idea is this:

          auto v1 = Vec!4(4, 5, 6, 7);
          auto v2 = v1.xyz;   // => Vec!3(4, 5, 6);
          auto v3 = v1.wx;    // => Vec!2(7, 4);
          auto v4 = v1.wxx1;  // => Vec!4(7, 4, 4, 1);


Okay, got it. Thanks to both you and David for the clarification. A bug 
report was filed:

https://issues.dlang.org/show_bug.cgi?id=13087
Jul 09 2014