On Friday, 25 September 2015 at 12:50:55 UTC, John Colvin wrote:
> The complexity of the tradeoff is exactly why experienced windows developers are necessary here. For example: any tradeoffs I designed would likely be very far from pareto-optimal on windows, let alone be a good solution overall.

No, a tradeoff is a tradeoff, one tradeoff is not better than another, it depends on priorities, not experience.

On Friday, 25 September 2015 at 13:03:47 UTC, Dicebot wrote:
> Hm, so is the correct approach on Windows to provide separate shell for each application that has console utilities? X_x

If tools conflict, they need a form of isolation. Like... make install 3 versions of gcc on your system and make them work.

On Friday, 25 September 2015 at 15:40:54 UTC, Kagamin wrote:
> On Friday, 25 September 2015 at 12:50:55 UTC, John Colvin wrote:
>> The complexity of the tradeoff is exactly why experienced windows developers are necessary here. For example: any tradeoffs I designed would likely be very far from pareto-optimal on windows, let alone be a good solution overall.
>
> No, a tradeoff is a tradeoff, one tradeoff is not better than another

That's what pareto-optimal means.

> it depends on priorities, not experience.

and what informs those priorities? My ideas of what is important on windows are not going to be as well informed as someone with more experience with the platform.

On Friday, 25 September 2015 at 15:40:54 UTC, Kagamin wrote:
> On Friday, 25 September 2015 at 13:03:47 UTC, Dicebot wrote:
>> Hm, so is the correct approach on Windows to provide separate shell for each application that has console utilities? X_x
>
> If tools conflict, they need a form of isolation. Like... make install 3 versions of gcc on your system and make them work.

What causes conflict? Is it just optilink? Maybe it would be more reasonable to simply rename it to something less generic? DMD doesn't look like something that inherently requires isolation.

Taking your example, installing 3 versions of gcc simultaneously is not that problematic if you don't need them all to be called `gcc`.

On Friday, 25 September 2015 at 15:43:46 UTC, John Colvin wrote:
> On Friday, 25 September 2015 at 15:40:54 UTC, Kagamin wrote:
>> On Friday, 25 September 2015 at 12:50:55 UTC, John Colvin wrote:
>>> The complexity of the tradeoff is exactly why experienced windows developers are necessary here. For example: any tradeoffs I designed would likely be very far from pareto-optimal on windows, let alone be a good solution overall.
>>
>> No, a tradeoff is a tradeoff, one tradeoff is not better than another
>
> That's what pareto-optimal means.

Well, a tradeoff is a choice between two pareto optimal variants :)

>> it depends on priorities, not experience.
>
> and what informs those priorities? My ideas of what is important on windows are not going to be as well informed as someone with more experience with the platform.

I suppose, PATH variable on windows works the same as on unix? And path hell can be easily reproduced on unix too. Nothing windows-specific here.

On 25-Sep-2015 19:06, Dicebot wrote:
> On Friday, 25 September 2015 at 15:40:54 UTC, Kagamin wrote:
>> On Friday, 25 September 2015 at 13:03:47 UTC, Dicebot wrote:
>>> Hm, so is the correct approach on Windows to provide separate shell
>>> for each application that has console utilities? X_x
>>
>> If tools conflict, they need a form of isolation. Like... make install
>> 3 versions of gcc on your system and make them work.
>
> What causes conflict? Is it just optilink? Maybe it would be more
> reasonable to simply rename it to something less generic? DMD doesn't
> look like something that inherently requires isolation.
>
> Taking your example, installing 3 versions of gcc simultaneously is not
> that problematic if you don't need them all to be called `gcc`.

That's the problem with Windows - every linker is just 'link', same goes for one hundred of incompatible 'make'-s...

-- 
Dmitry Olshansky

On Friday, 25 September 2015 at 16:06:23 UTC, Dicebot wrote:
> On Friday, 25 September 2015 at 15:40:54 UTC, Kagamin wrote:
>> On Friday, 25 September 2015 at 13:03:47 UTC, Dicebot wrote:
>>> Hm, so is the correct approach on Windows to provide separate shell for each application that has console utilities? X_x
>>
>> If tools conflict, they need a form of isolation. Like... make install 3 versions of gcc on your system and make them work.
>
> What causes conflict? Is it just optilink? Maybe it would be more reasonable to simply rename it to something less generic?

Yeah, that sounds like an easy solution :)

On Friday, 25 September 2015 at 16:06:44 UTC, Kagamin wrote:
> I suppose, PATH variable on windows works the same as on unix? And path hell can be easily reproduced on unix too. Nothing windows-specific here.

AFAIK, PATH on Windows works basically the same as it does on *nix, but a big difference is that on *nix, there are generally some very specific places where programs go, and almost nothing needs to touch PATH - e.g. a binary is usually going to be in /bin, /usr/bin, or /usr/local/bin, all of which are likely to be in your PATH variable. And if you installed something as your user, then you'd generally put the binary (or a symlink to it) in ~/bin. Windows really doesn't have anything like bin. Everything gets installed in its own directory (usually under Program Files), and if you want it to be usable on the command line, you have to add it to PATH. And since all of these programs are separate, they can have executables with the same name (e.g. link.exe), whereas that's much less likely on *nix, because almost all executables get installed to one of a few bin directories. So, you won't even end up installing conflicting binaries, because they'd overwrite each other.

I really don't know what the "correct" way to deal with this is in Windows, but the way that it's set up does seem to naturally cause more problems with PATH than you typically get in *nix.

- Jonathan M Davis

On Friday, 25 September 2015 at 09:58:16 UTC, ponce wrote:
> On Friday, 25 September 2015 at 00:25:54 UTC, Manu wrote:
>> I update DMD yesterday, it couldn't work out where it was installed and the uninstall fails, then complains and errors when trying to install over the failed uninstall, requiring manual intervention.
>
> I don't use the D installer because I don't trust it to deal with PATH correctly.

I use the installer just so I don't have to configure the VS paths, but I tell it not to modify the PATH variable. I also have a desktop shortcut configured to launch this:

%comspec% /k ""C:\D\dmd.bat""

Where dmd.bat is:
@set PATH=C:\dev\d\mars\dm\bin;%PATH%
@set PATH=%~dp0dmd2\windows\bin;%PATH%
@set PATH=%~dp0dmd2\windows\bin64;%PATH%
@set DC=dmd

And when I need to use a different version of the compiler, I use dvm. No problems so far.

On Friday, 25 September 2015 at 15:43:46 UTC, John Colvin wrote:
> On Friday, 25 September 2015 at 15:40:54 UTC, Kagamin wrote:
>> On Friday, 25 September 2015 at 12:50:55 UTC, John Colvin wrote:
>>> The complexity of the tradeoff is exactly why experienced windows developers are necessary here. For example: any tradeoffs I designed would likely be very far from pareto-optimal on windows, let alone be a good solution overall.
>>
>> No, a tradeoff is a tradeoff, one tradeoff is not better than another
>
> That's what pareto-optimal means.
>

<Putting on my economist hat>
Pareto optimal means you can't make anybody better off without making somebody worse off (you used it properly above...).

It's very easy to show that it's possible to have one trade-off be better than another. For instance, suppose I am indifferent between purchasing 1 TV or 1 computer. This is trade-off 1. Alternately, I am also indifferent between buying 2 TVs or 2 computers or 1 TV and 1 computer. This is trade-off 2. However, I prefer the second set of trade-offs to the first set of trade-offs because I prefer more stuff. I'm probably over-analyzing this...

An alternative to Pareto is Kalder-Hicks efficiency. A Kalder-Hicks improvement means that the people who are better off from some change are sufficiently better off from that change that they could compensate the people who are worse off from the change if they wanted to. Maybe that is a better framework for thinking about things.

On Friday, 25 September 2015 at 16:30:04 UTC, Jonathan M Davis wrote:
> I really don't know what the "correct" way to deal with this is in Windows, but the way that it's set up does seem to naturally cause more problems with PATH than you typically get in *nix.

Both work fine until you have conflicts. Imagine you want to use two versions of dmd in parallel.