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

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

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

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

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

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

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.

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.