On 2/8/13, Walter Bright <walter@digitalmars.com> wrote:
> http://ftp.digitalmars.com/dmd2beta.zip

A quick one: could you decide to ship rdmd.d with the zip, or
otherwise close http://d.puremagic.com/issues/show_bug.cgi?id=6412 as
wontfix? Thanks!
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Sat, 09 Feb 2013 00:13:34 +0100
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote:

> On Friday, February 08, 2013 18:00:11 Nick Sabalausky wrote:
> > I am tracking down one or two other problems now though, looks like at least one of them has to do with toString on a struct...
> 
> IIRC, it was supposed to have been fixed semi-recently so that toString on structs weren't so restrictive about their attributes (e.g. making it const should now work), so that may be related (though that might have been in 2.061; I don't remember).
> 

Whatever problem it is I'm tracking down was indeed introduced in 2.061. Due to some unfortunate timing, I didn't have a chance to test 2.061 during its beta.

The problem *seems* to involve a struct's toString not getting called by format(), but a trivial test of it seems to work fine. So I'm still narrowing it down...

There's also another problem I have with a certain opCmp not working
right (as of 2.061), but it might turn out to be the same problem, or
my own fault, or something else entirely. not sure yet...
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Fri, 8 Feb 2013 18:25:27 -0500
Nick Sabalausky <bus_dmdbeta@semitwist.com> wrote:

> On Sat, 09 Feb 2013 00:13:34 +0100
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote:
> 
> > On Friday, February 08, 2013 18:00:11 Nick Sabalausky wrote:
> > > I am tracking down one or two other problems now though, looks like at least one of them has to do with toString on a struct...
> > 
> > IIRC, it was supposed to have been fixed semi-recently so that toString on structs weren't so restrictive about their attributes (e.g. making it const should now work), so that may be related (though that might have been in 2.061; I don't remember).
> > 
> 
> Whatever problem it is I'm tracking down was indeed introduced in 2.061. Due to some unfortunate timing, I didn't have a chance to test 2.061 during its beta.
> 
> The problem *seems* to involve a struct's toString not getting called by format(), but a trivial test of it seems to work fine. So I'm still narrowing it down...
> 
> There's also another problem I have with a certain opCmp not working right (as of 2.061), but it might turn out to be the same problem, or my own fault, or something else entirely. not sure yet...

One of the problems turned out to be the following, which I'm guessing is probably intentional?:

    import std.stdio;

    struct Foo
    {
        string toString()
        {
            return "hello";
        }
    }

    void main()
    {
        const f = Foo();

        // In 2.061 and up, this outputs "const(Foo)()"
        // instead of "hellO". A fixed bug?
        writeln(f);
    }

Making toString 'const' seems to make the problem go away, so I'm guessing this is as intended. Kind of a pain though, as it means the const-version of a struct can easily end up with accidentally different behavior.

I'm still tracking down the other problem I'm having, involving a
struct that no longer works correctly as an AA key (again, as of
2.061, but still failing in this beta). I have a feeling this may be a
const-ness problem too, though I'm not certain yet.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 08.02.2013 09:30, Walter Bright wrote:
> http://ftp.digitalmars.com/dmd2beta.zip
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

I'd like to see the installation for Win64 sorted out. The major issue for that to work seamlessly right now is that the user has to edit sc.ini to adjust it to his environment. There is also a mixture of COFF and OMF libraries in the lib folder now that is just asking for trouble.

One problem is how to detect the location of the Microsoft linker, the MS runtime library and the platform SDK libraries. This is currently done by hardcoding the location into sc.ini setting the environment variables VCINSTALLDIR and WindowsSdkDir. But these might also be set by the user in the environment (e.g. by starting the respective console window) or can be detected from the registry. A Visual Studio and Windows SDK directory structure is currently assumed, but it does not match the Windows 8 SDK, for example.

My suggestion:

- add a new assignment operator "?=" to the ini file handler that just overwrites environment variables that don't have a value yet.

- add a new special syntax "%@[registry-value]%" to read a registry value

- put Win64 libraries into a separate directory "lib64"

- make use of the [Environment64] block in sc.ini, e.g.

[Environment64]
VCINSTALLDIR?=%@[HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VC\ProductDir]
VCINSTALLDIR?=%@[HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\Setup\VC\ProductDir]
VCINSTALLDIR?=%@[HKLM\SOFTWARE\Microsoft\VisualStudio\11.0\Setup\VC\ProductDir]
VCINSTALLDIR?=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC

WindowsSdkDir?=%@[HKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows\CurrentInstallFolder]
WindowsSdkDir?=%@[HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows Kits\Installed Roots\KitsRoot]
WindowsSdkDir?=C:\Program Files\Microsoft SDKs\Windows\v6.0A

LINKCMD=%VCINSTALLDIR%\bin\amd64\link.exe

LIB=%@P%\..\lib64;%VCINSTALLDIR%\lib\amd64;%WindowsSdkDir%\lib\x64;%WindowsSdkDir%\lib\win8\um\x64

DFLAGS=%DFLAGS -L/nologo

* No need to have a new variable LINKCMD64.

* The fallback to standard paths could also benefit from some mechanism that checks whether the previous settings points to an existing directory or file.

* A few more entries might be needed to deal with VS Express versions

* throw out a some hardcoded linker options from link.c

Is this the way to go? To do a pull request for this, it would be good to also have the installed sc.ini available on github.

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

2013/2/9 Nick Sabalausky <bus_dmdbeta@semitwist.com>

> On Fri, 8 Feb 2013 18:25:27 -0500
> Nick Sabalausky <bus_dmdbeta@semitwist.com> wrote:
> One of the problems turned out to be the following, which I'm guessing
> is probably intentional?:
>
>     import std.stdio;
>
>     struct Foo
>     {
>         string toString()
>         {
>             return "hello";
>         }
>     }
>
>     void main()
>     {
>         const f = Foo();
>
>         // In 2.061 and up, this outputs "const(Foo)()"
>         // instead of "hellO". A fixed bug?
>         writeln(f);
>     }
>

This behavior (formatting const Foo object by writeln) is at least from
2.058.

The result of const Foo object formatting by std.string.format is changed from 2.061, to make it consistent with the result by writeln.

Kenji Hara

On Sat, 9 Feb 2013 18:03:53 +0900
kenji hara <k.hara.pg@gmail.com> wrote:

> 2013/2/9 Nick Sabalausky <bus_dmdbeta@semitwist.com>
> 
> > On Fri, 8 Feb 2013 18:25:27 -0500
> > Nick Sabalausky <bus_dmdbeta@semitwist.com> wrote:
> > One of the problems turned out to be the following, which I'm
> > guessing is probably intentional?:
> >
> >     import std.stdio;
> >
> >     struct Foo
> >     {
> >         string toString()
> >         {
> >             return "hello";
> >         }
> >     }
> >
> >     void main()
> >     {
> >         const f = Foo();
> >
> >         // In 2.061 and up, this outputs "const(Foo)()"
> >         // instead of "hellO". A fixed bug?
> >         writeln(f);
> >     }
> >
> 
> This behavior (formatting const Foo object by writeln) is at least
> from 2.058.
> 
> The result of const Foo object formatting by std.string.format is changed from 2.061, to make it consistent with the result by writeln.
> 

Ok, my original code *is* using format which is why it didn't break
until 2.061. I ended up changing it to writefln only for the minimized
test case above. Didn't realize there was a difference.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Fri, 8 Feb 2013 18:25:27 -0500
Nick Sabalausky <bus_dmdbeta@semitwist.com> wrote:
> 
> There's also another problem I have with a certain opCmp not working right (as of 2.061), but it might turn out to be the same problem, or my own fault, or something else entirely. not sure yet...

Ok, the problem I was having turned out to be this:

In my struct, I originally had this:

------------------------------------
bool opEquals(ref const Insensitive b) const {...}
int opCmp(ref const Insensitive b) const {...}
------------------------------------

Starting with 2.061, those silently failed to get called (when looking up the struct as an AA key), and I had to change them to this:

------------------------------------
bool opEquals(const Insensitive b) const { return opEquals(b); }
bool opEquals(ref const Insensitive b) const {...}

int opCmp(const Insensitive b) const { return opCmp(b); }
int opCmp(ref const Insensitive b) const {...}
------------------------------------

Note that auto ref (as below) failed to work because it silently fails
to get called on all versions of DMD I tried (2.060, 2.061 and this
2.062 beta):

------------------------------------
bool opEquals()(auto ref const Insensitive b) const {...}
int opCmp()(auto ref const Insensitive b) const {...}
------------------------------------

It took me literally hours to figure all this out, largely because the
changelog for 2.061 appears to make no mention of any of it (unless it's
buried somewhere in bugzilla, but I couldn't find it when I looked
just now).

This is a perfect example of why the changelog needs to go back to
*not* being nearly-useless. That, and the constant NG posts of "How
the changelog's download link for the latest version, 2.062, is broken?"
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 2/9/2013 3:07 PM, Nick Sabalausky wrote:


This is a perfect example of why the changelog needs to go back to
*not* being nearly-useless.


The changelog wasn't better before, and there was nothing in about the text in the 'before' 2.061 that would have made things better for this particular issue.

>   That, and the constant NG posts of "How
> the changelog's download link for the latest version, 2.062, is broken?"
>

That's more an issue of a difference between what should be put live on the website and ongoing improvements that should go in the next release.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Fri, 8 Feb 2013 04:01:08 -0500
Nick Sabalausky <bus_dmdbeta@semitwist.com> wrote:
> 
> Ugly: The CSS file doesn't get found and picked up when viewing the off-line HTML docs.

Filed:
http://d.puremagic.com/issues/show_bug.cgi?id=9492
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 2/9/13, Rainer Schuetze <r.sagitario@gmx.de> wrote:
> One problem is how to detect the location of the Microsoft linker, the MS runtime library and the platform SDK libraries.

I already gave Walter a batch file for 2.061 which can be invoked to
retrieve these paths, but it went completely ignored.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta