On Sunday, 21 May 2017 at 22:47:44 UTC, Jolly James wrote:
> On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:
>> Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227
>
> I really like this philosophy:
> "It does not work, a fix is available, but it won't be rolled out (for now). Who cares about those who cannot use the broken software?"

Yeah great. However its actually working, one just have to set up paths manually. Just a little inconvenience.

On Sunday, 21 May 2017 at 22:47:44 UTC, Jolly James wrote:
> On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:
>> Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227
>
> I really like this philosophy:
> "It does not work, a fix is available, but it won't be rolled out (for now). Who cares about those who cannot use the broken software?"

Please don't antagonize volunteer contributors who are actually creating and improving things. We have a release process for a reason, we can't ship every single change immediately. If you require a solution urgently, use a workaround or build it from source yourself.

On Monday, 22 May 2017 at 07:28:23 UTC, Vladimir Panteleev wrote:
> On Sunday, 21 May 2017 at 22:47:44 UTC, Jolly James wrote:
>> On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:
>>> Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227
>>
>> I really like this philosophy:
>> "It does not work, a fix is available, but it won't be rolled out (for now). Who cares about those who cannot use the broken software?"
>
> Please don't antagonize volunteer contributors who are actually creating and improving things. We have a release process for a reason, we can't ship every single change immediately. If you require a solution urgently, use a workaround or build it from source yourself.

My message was neither addressed directly to anybody of the volunteer contributors (I have a huge respect of them and their great work), nor to anyone at the D Foundation directly. I just wanted to critize the whole release cycle stuff itself.

I mean, if for any circumstance, e.g. like the VS2017 thing (which did not suddenly appear from one day to another anyway), the whole software cannot be used without larger fiddling (in this case: setting up NSIS + plugins), it seems quite strange to not simply update the installer, which would be a work for a few minutes - and after that everybody would be happy.
But to be honest, I don't think that this is a problem of D. More or less, this is something that appears everywhere in the world of open-source. Here it annoys and chases away users, in the corporate sector you could not do so, as this would cause the company's ruin.

On Monday, 22 May 2017 at 21:08:02 UTC, Jolly James wrote:
> I mean, if for any circumstance, e.g. like the VS2017 thing (which did not suddenly appear from one day to another anyway), the whole software cannot be used without larger fiddling (in this case: setting up NSIS + plugins), it seems quite strange to not simply update the installer, which would be a work for a few minutes - and after that everybody would be happy.
> But to be honest, I don't think that this is a problem of D. More or less, this is something that appears everywhere in the world of open-source. Here it annoys and chases away users, in the corporate sector you could not do so, as this would cause the company's ruin.

D's implementation (which is a part of the project as a whole) is cross-platform, we support several platforms other than Windows. Additionally, Visual Studio integration is an optional feature of the Windows version, and of course VS2017 is just one supported version of VS. The scope of the problem may seem larger to you because you are affected by it personally, however at any point in time there may be any number of fixes queued for release of similar relative importance. Making an urgent release for every such occurrence would be impractical, if not impossible given the necessary work involved with making each new release.

The difference between open-source and proprietary projects here is mainly that open-source projects do their development in the open. Generally, users usually are not made aware of the status of any particular fix or issue for proprietary projects up until the point that they appear in the changelog of a published release. Heck, most proprietary projects don't even have public bug trackers, or even forums for that matter.

On Monday, 22 May 2017 at 21:08:02 UTC, Jolly James wrote:
> On Monday, 22 May 2017 at 07:28:23 UTC, Vladimir Panteleev wrote:
>> On Sunday, 21 May 2017 at 22:47:44 UTC, Jolly James wrote:
>>> On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:
>>>> Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227
>>>
>>> I really like this philosophy:
>>> "It does not work, a fix is available, but it won't be rolled out (for now). Who cares about those who cannot use the broken software?"
>>
>> Please don't antagonize volunteer contributors who are actually creating and improving things. We have a release process for a reason, we can't ship every single change immediately. If you require a solution urgently, use a workaround or build it from source yourself.
>
> My message was neither addressed directly to anybody of the volunteer contributors (I have a huge respect of them and their great work), nor to anyone at the D Foundation directly. I just wanted to critize the whole release cycle stuff itself.
>
> I mean, if for any circumstance, e.g. like the VS2017 thing (which did not suddenly appear from one day to another anyway), the whole software cannot be used without larger fiddling (in this case: setting up NSIS + plugins), it seems quite strange to not simply update the installer, which would be a work for a few minutes - and after that everybody would be happy.
> But to be honest, I don't think that this is a problem of D. More or less, this is something that appears everywhere in the world of open-source. Here it annoys and chases away users, in the corporate sector you could not do so, as this would cause the company's ruin.

We already have nightly builds for all platforms supported by dmd [0]. We just need a nightly build of the installer, in addition to the 7zip archive for Windows. So I'd say we're already doing much better than 1-2 years ago.

[0]: http://nightlies.dlang.org/dmd-master-2017-05-23/

On Monday, 22 May 2017 at 23:58:37 UTC, Vladimir Panteleev wrote:
> Additionally, Visual Studio integration is an optional feature of the Windows version, and of course VS2017 is just one supported version of VS.
Come one, let's be ones: If DMD has no x64 linker, VS integration is not a bit optional.

> The scope of the problem may seem larger to you because you are affected by it personally, however at any point in time there may be any number of fixes queued for release of similar relative importance. Making an urgent release for every such occurrence would be impractical, if not impossible given the necessary work involved with making each new release.

So you are telling me "not working at all" is not worth releasing a fix? xD

On Tuesday, 23 May 2017 at 23:11:30 UTC, Jolly James wrote:
> Come one, let's be ones: If DMD has no x64 linker, VS integration is not a bit optional.

Unlike some other operating systems, 64-bit Windows versions can run 32-bit software just fine. If you require targeting Win64 (or the Microsoft C runtime), that is specific to your use case.

And, again, Visual Studio is not required if you want to target Win64 - only the necessary toolchain components (linker and C runtime), which you can also obtain from an SDK.

> So you are telling me "not working at all" is not worth releasing a fix? xD

Again, everything should be already working. We are talking about a convenience feature that automatically sets up the D compiler's configuration file, nothing more. That's all there is to the "integration". You can trivially do the same thing by hand, or set up your environment accordingly - all in a fraction of the time it took you to write these pointless complaints on this forum.

On Wednesday, 24 May 2017 at 03:21:56 UTC, Vladimir Panteleev wrote:
> On Tuesday, 23 May 2017 at 23:11:30 UTC, Jolly James wrote:
>> Come one, let's be ones: If DMD has no x64 linker, VS integration is not a bit optional.
>
> Unlike some other operating systems, 64-bit Windows versions can run 32-bit software just fine. If you require targeting Win64 (or the Microsoft C runtime), that is specific to your use case.

That's true. But when D's GC does not trigger early enough, my program runs out of memory (due to the 2 GB limit of 32 bit process), x64 solves this more or less. As a side note: I am talking about allocating huge arrays.


> And, again, Visual Studio is not required if you want to target Win64 - only the necessary toolchain components (linker and C runtime), which you can also obtain from an SDK.
>
>> So you are telling me "not working at all" is not worth releasing a fix? xD
>
> Again, everything should be already working. We are talking about a convenience feature that automatically sets up the D compiler's configuration file, nothing more. That's all there is to the "integration". You can trivially do the same thing by hand, or set up your environment accordingly - all in a fraction of the time it took you to write these pointless complaints on this forum.

I admit, you are right in some points. Nevertheless, have you ever tried letting a novice configuring this stuff? The 'sc.ini' is neither easy to read nor logic. In my particular case I am overchallenged by this task.

On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:
>
>
> On 01.05.2017 10:03, Igor wrote:
>> On Monday, 1 May 2017 at 01:54:30 UTC, evilrat wrote:
>>> [...]
>>
>> That was it. It didn't occur to me that this was the problem because I
>> payed closed attention during VisualD installation and saw it properly
>> recognized where DMD was installed but for some reason the path wasn't
>> set in Options. Once I did set it, compile and build worked. Thanks
>> evilrat!
>>
>> So in conclusion it seems the problem is in VisualD installation which
>> doesn't set the path properly even though it recognizes where DMD is
>> installed. Hope the author takes a look at this problem so beginners
>> wanting to try D don't give up on a problem like this.
>
> VS 2017 uses a "private" registry that the Visual D installer doesn't have access to. I'll change the registry location in the next release.
>
> Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227

Today I saw that a new DMD version had been released. So I downloaded it (dmd-2.074.1.exe).

Unfortunately, the installer does *not* detect VS2017, instead it asks me to install VS2013 for x64 support.

On Sunday, June 04, 2017 16:03:46 Jolly James via Digitalmars-d wrote:
> On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:
> > On 01.05.2017 10:03, Igor wrote:
> >> On Monday, 1 May 2017 at 01:54:30 UTC, evilrat wrote:
> >>> [...]
> >>
> >> That was it. It didn't occur to me that this was the problem
> >> because I
> >> payed closed attention during VisualD installation and saw it
> >> properly
> >> recognized where DMD was installed but for some reason the
> >> path wasn't
> >> set in Options. Once I did set it, compile and build worked.
> >> Thanks
> >> evilrat!
> >>
> >> So in conclusion it seems the problem is in VisualD
> >> installation which
> >> doesn't set the path properly even though it recognizes where
> >> DMD is
> >> installed. Hope the author takes a look at this problem so
> >> beginners
> >> wanting to try D don't give up on a problem like this.
> >
> > VS 2017 uses a "private" registry that the Visual D installer doesn't have access to. I'll change the registry location in the next release.
> >
> > Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227
>
> Today I saw that a new DMD version had been released. So I
> downloaded it (dmd-2.074.1.exe).
>
> Unfortunately, the installer does *not* detect VS2017, instead it asks me to install VS2013 for x64 support.

That PR was merged into the master branch, not the stable branch, so the updates to the installer will be in 2.075.0. Presumably, they either thought that it was too large a change for a release that only has bugfixes, or they just merged it into master, because that's the default, and they didn't think about it.

- Jonathan M Davis