On Thursday, 22 August 2013 at 03:38:26 UTC, Tyler Jameson Little wrote:
>
> Do we really want D1 compilers that easily accessable?

Considering D1 has an entire site of its own[0], why are they even there?  Move them to where they belong with a BIG RED BANNER saying they're EOL and an "are you sure you want this?" confirmation to download them.

-Wyatt

[0] http://www.digitalmars.com/d/1.0/

On 22 August 2013 17:33, Jacob Carlborg <doob@me.com> wrote:

> On 2013-08-22 05:33, Manu wrote:
>
>  I was also briefly confused by the 32bit/64bit scattered everywhere. My
>> initial assumption was that it specified the toolchain's target
>> architecture :/
>> But since it's the compiler's host arch, I'd say that for Windows where
>> 32bit binaries will run on any version of windows and no 64bit binary is
>> offered, and OSX which has only ever been 64bit, there's no need to
>> write it for those platforms. It's just confusing.
>>
>
> The architecture are basically never mentioned for Mac OS X downloads. Because everyone assumes universal binaries that will work everywhere.


... what?
Isn't that what I just said?
Did you actually look at Brad's page upgrade?

On 22 August 2013 17:32, Jacob Carlborg <doob@me.com> wrote:

> On 2013-08-22 05:07, Manu wrote:
>
> But there's still no LDC binary there... where is it?
>>
>
> I don't know if they were recently added but they are below the GDC binaries.
>

Can't see any. I can only see binaries for platforms that nobody uses ;)

On 2013-08-22 16:01, Manu wrote:

> ... what?
> Isn't that what I just said?
> Did you actually look at Brad's page upgrade?

No, you said it doesn't need to be mentioned since it's only been released as 64bit. I was referring to, that in general, most open source projects, like D, don't mention the architecture for Mac OS X. Either it's a universal binary working on all platforms or it's a 32bit binary, works everywhere as well, or it's a 64bit binary because all Mac these days can run 64bit binaries.

-- 
/Jacob Carlborg

On 2013-08-22 16:04, Manu wrote:

> Can't see any. I can only see binaries for platforms that nobody uses ;)

I didn't see you mention any platform in the post I replied to ;)

-- 
/Jacob Carlborg

On Thursday, 22 August 2013 at 03:07:39 UTC, Manu wrote:
> And why is there no LDC binary?

There are links to the LDC Linux/OS X binaries on the dlang.org download page.

As for the Windows/MinGW32 binaries, the last LDC release does officially include them (see the release announcement), but the MinGW port is still very much in an alpha/beta state.

For example, there is still at least one wrong-code issues with 80 bit reals, and the test suite does not completely pass yet. Somewhat contrary to GDC, in case of LDC there are actual released versions that are guaranteed to be stable to a certain extent (i.e. the test suite passes on all relevant systems, …), and I was afraid that prematurely advertising the relatively fresh MinGW port would draw a wrong picture of the overall quality.

As the GDC/MinGW binaries are probably not more stable either, though, yet are linked on the dlang.org download page, I guess we should add the LDC MinGW link to the page as well, if maybe qualified with an "experimental" note.

Another issue is that a fairly recent mingw-w64 snapshot is needed in addition to the LDC download for GCC (linker, libraries). Older ones don't have my necessary fixes yet, and I don't know if they have made it into the "original" MinGW (without -w64) project yet. What would be the best way to add this to the/a download page?

In any case, you are right, the wiki.dlang.org/LDC "landing page" definitely needs to be either replaced with a proper homepage with download link auto-detection, …, or at least reorganized in such a way that the most important links for  new users, users wanting to report bugs/… as well as developers are clearly presented at the top (the first link in the "Getting Started" section would have been what you were looking for).

David

On 23 August 2013 07:49, David Nadlinger <code@klickverbot.at> wrote:

> On Thursday, 22 August 2013 at 03:07:39 UTC, Manu wrote:
>
>> And why is there no LDC binary?
>>
>
> There are links to the LDC Linux/OS X binaries on the dlang.org download page.
>
> As for the Windows/MinGW32 binaries, the last LDC release does officially include them (see the release announcement), but the MinGW port is still very much in an alpha/beta state.
>

Oh okay. Well it would definitely be worth writing that somewhere.
I knew it worked (more-or-less) on Windows, I've built it from source
before and created working code. But last time I used it there was still no
Win64 exceptions.
My thread is really about the experience as an end-user trying to get a
working compiler; It shouldn't be hard.

For example, there is still at least one wrong-code issues with 80 bit
> reals, and the test suite does not completely pass yet. Somewhat contrary
> to GDC, in case of LDC there are actual released versions that are
> guaranteed to be stable to a certain extent (i.e. the test suite passes on
> all relevant systems, …), and I was afraid that prematurely advertising the
> relatively fresh MinGW port would draw a wrong picture of the overall
> quality.
>

I think people would appreciate this, but it's probably worth writing this
clearly on the download page.
A binary marked very clearly as alpha/beta, and perhaps a list of known
issues might be nice for end users to access at a glance.

As the GDC/MinGW binaries are probably not more stable either, though, yet
> are linked on the dlang.org download page, I guess we should add the LDC MinGW link to the page as well, if maybe qualified with an "experimental" note.
>

Mmm.
Well, I can't make the GDC binaries work at all... there are missing
dependencies.

Another issue is that a fairly recent mingw-w64 snapshot is needed in
> addition to the LDC download for GCC (linker, libraries). Older ones don't have my necessary fixes yet, and I don't know if they have made it into the "original" MinGW (without -w64) project yet. What would be the best way to add this to the/a download page?
>

Would it be better to produce a distribution package that includes the
working mingw snapshot? It's quite annoying when a distro package has
dependencies.
I think Windows end-users aren't used to meticulous versioning like Linux
users. Things like version numbers are rarely in the paths/filenames. The
result of this is, they might already have a mingw on their system that
they presume is fine (or don't know is fine), or may be reluctant to
install another instance of a package they already have, thinking it's
basically the same.
Putting everything in the one package sounds more fool-proof to me.

Just a thought that might be convenient for users would be if LDC and GDC collaborated on a single complete mingw package that included both GDC and LDC compilers... Perhaps annoying to maintain/coordinate, but I'd say at this point, most users will end out with both toolchains on their system anyway, and when you have multiple mingw installations on a machine, the PATH variable get's kinda awkward.

On 23 August 2013 10:05, Manu <turkeyman@gmail.com> wrote:

> On 23 August 2013 07:49, David Nadlinger <code@klickverbot.at> wrote:
>
>> On Thursday, 22 August 2013 at 03:07:39 UTC, Manu wrote:
>>
>>> And why is there no LDC binary?
>>>
>>
>> There are links to the LDC Linux/OS X binaries on the dlang.org download page.
>>
>> As for the Windows/MinGW32 binaries, the last LDC release does officially include them (see the release announcement), but the MinGW port is still very much in an alpha/beta state.
>>
>
> Oh okay. Well it would definitely be worth writing that somewhere.
>

And by 'somewhere', I mean, somewhere along the standard download path:
dlang.org -> dlang.org/download.html -> ??? .. and probably at the very top
of the wiki where it's impossible to miss.
Forum posts/blogs probably aren't the best location for critical end-user
facing information :)

On Thursday, 22 August 2013 at 07:34:09 UTC, Jacob Carlborg wrote:
> On 2013-08-22 06:28, Tyler Jameson Little wrote:
>
>> Why not sniff the platform? I think Firefox & Dart websites do this.
>> This can be retrieved with navigator.platform:
>> https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.platform
>>
>> Of course, the others should be easily accessible.
>
> Or just using the user agent, since it has to work on all major browsers.

Right, and doing it server-side would allow users with JS disabled to still be supported.

Any support for this would be miles ahead of the current situation.