Pathing in the D ecosystem is generally broken (at least on windows)
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. Then I try and build with LDC, it can't link anymore because paths are messed up and when looking for link.exe (microsoft's linker) it finds optlink link.exe instead. I tried to use a tool in VisualD which disassembles some code, but it can't find the tools it needs to do the job! This is silly. I don't know how such simple things can be so consistently hard?! My first and most frequent problems with the D ecosystem were pathing issues, and that's still more-or-less the case today. It's been 6 years for me. I'm getting tired. Can we please make an effort to get the paths right? This might mean some intelligence is required to make it work; check if the tool is the right tool? If it's not, keep looking? If tools can't be found, produce a dialog box prompting the user to supply the proper path to the tool? MSVC interaction (DMD-COFF and LDC) should probably leverage Microsoft's command line scripts, which are located in reliable places, and work reliably. MSCV associated tools shouldn't be capable of finding optlink by mistake. As a rule, no tool should ever require a windows user to interact with their path variable. It's a colossal mess, windows doesn't do 'PATH'. Mine has an endless list of bin directories, and many/most of them provide duplicates of the same programs. A robust program can never rely on PATH. Here's a typical PATH configured for the tools I use in my office: %QTDIR%/bin;%LDC_ROOT%\bin;C:\dev\wxWidgets-3.0.2\lib\gcc_dll;C:\dev\CMake\bin;C:\dev\LLVM\bin;C:\Program Files (x86)\Microsoft VS Code\bin;C:\dev\Python27\;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;c:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\dev\dub;C:\dev\Emscripten\clang\e1.27.0_64bit;C:\dev\Emscripten\node\0.10.17_64bit;C:\dev\Emscripten\python\2.7.5.3_64bit;C:\dev\Emscripten\java\7.45_64bit\bin;C:\dev\Emscripten;C:\dev\Emscripten\emscripten\1.27.0;C:\dev\Emscripten\crunch\1.03;C:\dev\Emscripten\mingw\4.6.2_32bit;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files (x86)\Git\cmd;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\TortoiseGit\bin;C:\dev\D\dmd2\windows\bin This is minimal compared to my home dev environment (ie, is a controlled office PC). Surely this is evidence enough to conclude that no tool should *EVER* refer to PATH to find tools? The installer should remember where it installed last time! This requires action from every tool in the ecosystem, to include a little bit of logic that allows it to validate that paths are configured correctly and that the program _works_, and do something useful or ideally *helpful* if they're not.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 00:25:54 UTC, Manu wrote: MSVC interaction (DMD-COFF and LDC) should probably leverage Microsoft's command line scripts, which are located in reliable places, and work reliably. MSCV associated tools shouldn't be capable of finding optlink by mistake. If you agree that to get dmd working one must run it in a specially prepared command prompt, that can work.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
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. [...] There seems to be a trend here: Windows devs have problems getting D to install/work correctly on their machines. Non-windows devs boot up windows and test it and it works fine for them (In this case that was me). I seriously doubt that much progress will be made here unless some dedicated full-time modern Windows developers take over or at least significantly help with the installer code. Someone like you has years of experience and knowledge about what are good/bad solutions on windows, what workarounds/hacks are OK and which will be abhorrent to users, what will likely break in newer versions of windows/VS etc. etc. etc. Realistically, no-one except an experienced full-time windows developer is ever going to get this right.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 00:25:54 UTC, Manu wrote: As a rule, no tool should ever require a windows user to interact with their path variable. It's a colossal mess, windows doesn't do 'PATH'. Mine has an endless list of bin directories, and many/most of them provide duplicates of the same programs. A robust program can never rely on PATH. I also got the same problems. For LDC is is currently necessary to have VS2015 and fix-up paths like that: The PATH varible should preferably omit the DMD path and include: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE The LIB env-variable should have the paths: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64 C:\Program Files (x86)\Windows Kits\10\lib\10.0.10150.0\ucrt\x64 C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6\lib\um\x64 C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64 Super-annoying to do so I have a tool that call DUB frontend to do that (it also build Mac bundles). I'm not sure whose job it is to put things in PATH or LIB. But as it is, everyone that tries will stumble onto this.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
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.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 09:03:35 UTC, John Colvin wrote: On Friday, 25 September 2015 at 00:25:54 UTC, Manu wrote: [...] There seems to be a trend here: Windows devs have problems getting D to install/work correctly on their machines. Non-windows devs boot up windows and test it and it works fine for them (In this case that was me). [...] only talking about dmd here, I didn't try ldc.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 09:03:35 UTC, John Colvin wrote: Realistically, no-one except an experienced full-time windows developer is ever going to get this right. It's not a simple tradeoff: Manu's usual requirement is that dmd must work at the utmost ease of use even if heavens crash. Correct behavior is possible, but the question is how much user experience he would like to sacrifice for correctness.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 12:17:42 UTC, Kagamin wrote: On Friday, 25 September 2015 at 09:03:35 UTC, John Colvin wrote: Realistically, no-one except an experienced full-time windows developer is ever going to get this right. It's not a simple tradeoff: Manu's usual requirement is that dmd must work at the utmost ease of use even if heavens crash. Correct behavior is possible, but the question is how much user experience he would like to sacrifice for correctness. 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.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
Hm, so is the correct approach on Windows to provide separate shell for each application that has console utilities? X_x
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 09:03:35 UTC, John Colvin wrote: There seems to be a trend here: Windows devs have problems getting D to install/work correctly on their machines. Non-windows devs boot up windows and test it and it works fine for them (In this case that was me). I was never able to make it work on Windows apart from trivial hello-world. Though I highly suspect my definition of "works" would be very very different from one Manu has in mind.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
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.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
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.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
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
Re: Pathing in the D ecosystem is generally broken (at least on windows)
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.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
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`.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
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 :)
Re: Pathing in the D ecosystem is generally broken (at least on windows)
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
Re: Pathing in the D ecosystem is generally broken (at least on windows)
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.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
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. 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.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
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.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 16:43:48 UTC, Mike Parker wrote: 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. Wow, if it has that option, that's cool.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 17:47:11 UTC, Kagamin wrote: 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. It is normally solved by embedding version name in a binary and providing symlink to the default (i.e. pytjon2 vs python3)
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 18:44:08 UTC, Dicebot wrote: It is normally solved by embedding version name in a binary and providing symlink to the default (i.e. pytjon2 vs python3) Not imagine they depend on a third utility, which they assume to be on path and don't provide a way to override its name.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
BTW, it's not very difficult to invoke the linker directly.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 19:03:16 UTC, Kagamin wrote: On Friday, 25 September 2015 at 18:44:08 UTC, Dicebot wrote: It is normally solved by embedding version name in a binary and providing symlink to the default (i.e. pytjon2 vs python3) Not imagine they depend on a third utility, which they assume to be on path and don't provide a way to override its name. This is one of many reasons we (package maintainers) don't want to allow developers to do own packaging and distribution ;) It is somewhat common to patch upstream to resolve to proper binary names.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 19:32:10 UTC, Dicebot wrote: This is one of many reasons we (package maintainers) don't want to allow developers to do own packaging and distribution ;) It is somewhat common to patch upstream to resolve to proper binary names. With prepared environment it works without making you a compiler developer and devising smart versioning and naming schemes and without deep configurability everywhere.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
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. Then I try and build with LDC, it can't link anymore because paths are messed up and when looking for link.exe (microsoft's linker) it finds optlink link.exe instead. I tried to use a tool in VisualD which disassembles some code, but it can't find the tools it needs to do the job! This is silly. I don't know how such simple things can be so consistently hard?! My first and most frequent problems with the D ecosystem were pathing issues, and that's still more-or-less the case today. It's been 6 years for me. I'm getting tired. Can we please make an effort to get the paths right? This might mean some intelligence is required to make it work; check if the tool is the right tool? If it's not, keep looking? If tools can't be found, produce a dialog box prompting the user to supply the proper path to the tool? MSVC interaction (DMD-COFF and LDC) should probably leverage Microsoft's command line scripts, which are located in reliable places, and work reliably. MSCV associated tools shouldn't be capable of finding optlink by mistake. As a rule, no tool should ever require a windows user to interact with their path variable. It's a colossal mess, windows doesn't do 'PATH'. Mine has an endless list of bin directories, and many/most of them provide duplicates of the same programs. A robust program can never rely on PATH. [snip] This is minimal compared to my home dev environment (ie, is a controlled office PC). Surely this is evidence enough to conclude that no tool should *EVER* refer to PATH to find tools? dmd, as it is installed, doesn't. The installer does detect and set the direct paths for all of the Visual C integration with sc.ini. It uses the values set by Visual C in the Windows registry. It's designed to be idiot proof. It doesn't touch the system/user PATH environment variable for this purpose (just the PATH dmd itself uses). The installer can optionally update the PATH to add dmd (years ago I also added a Visual C Command Window style shortcut to the installer for users that didn't want to change their PATH). Take a look at the current sc.ini[1]. It describes how it all works. You never have to change your system/user PATH to get anything to work. The installer should remember where it installed last time! I just use the defaults so I've never bothered to implement this. Pull requests welcome, of course. Sounds trivial. This requires action from every tool in the ecosystem, to include a little bit of logic that allows it to validate that paths are configured correctly and that the program _works_, and do something useful or ideally *helpful* if they're not. Perhaps there are problems in LDC and VisualD but vanilla dmd has been pretty solid in this area for awhile now. Rainer just recently added support for VS2015. I'm not sure if it's in the latest release. Perhaps you could share your sc.ini and some more information about the uninstall error you hit. It's kind of difficult to fix any bugs when the description is vague and you seem to be the only one experiencing it. 1. https://github.com/D-Programming-Language/dmd/blob/master/ini/windows/bin/sc.ini#L31
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 17:48:50 UTC, Kagamin wrote: On Friday, 25 September 2015 at 16:43:48 UTC, Mike Parker wrote: 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. Wow, if it has that option, that's cool. It has for many releases now. There seems to be some out of date information people have about what the installer does. Here's some of the changes me and others have made over the years. - Setting the PATH is optional. - The installer detects and sets the paths to all the necessary Visual C++ stuff in sc.ini. - The installer provides two shortcuts to command prompts configured with DMD and the necessary Visual Studio paths set up, one for a 32-bit environment and one for a 64-bit environment (just like Visual C++ does). I added this just for people who don't like having their PATH changed but still wanted something that worked out of the box. - It no longer downloads the zip file and unpacks it, unix stuff and all, into the installation directory. Only the windows specific portion is included and it is embedded inside the installer. - If it can't detect Visual C++ it offers to download the latest Community Edition for you. - It can download and install Visual D. - It warns before uninstalling your old version (in case you've customized your DMD in some way). - OMF format libcurl is included now. - It won't nuke the PATH environment variable due to a bug that was in NSIS (this was my first contribution to D years ago).
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 23:15:29 UTC, Brad Anderson 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. Looks like Rainer may have already fixed your uninstallation problem[1]. Hard to say though without known more. 1. https://github.com/D-Programming-Language/installer/commit/9d90f955ac30854fcb33a1458e8b7f82549835d9
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 09:03:35 UTC, John Colvin 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. [...] There seems to be a trend here: Windows devs have problems getting D to install/work correctly on their machines. Non-windows devs boot up windows and test it and it works fine for them (In this case that was me). Thousands of developers download and use the installer just fine. Right after Walter added 64-bit support it was a chore for each developer to get it working but it's designed to Just Work these days (Martin even recently made it offer to download Visual Studio and install it for you). I don't think this is a Windows-dev vs non-Windows-dev issue, it's an atypical setup issue. There is also a history of the installer not being very good years ago so some of the veteran D users have an understandable bias against it. I seriously doubt that much progress will be made here unless some dedicated full-time modern Windows developers take over or at least significantly help with the installer code. Someone like you has years of experience and knowledge about what are good/bad solutions on windows, what workarounds/hacks are OK and which will be abhorrent to users, what will likely break in newer versions of windows/VS etc. etc. etc. Realistically, no-one except an experienced full-time windows developer is ever going to get this right. That's kind of what happened. I started using D and the installer sucked. I'm no NSIS ninja but I do use NSIS for our commercial product at work so I was somewhat familiar with it and slowly made improvements to it. Rainer, Martin, and Vladimir all contributed things too. Personally I think it's in great shape these days. I can't think of a single thing I'd change about it. It's simple and svelte but does everything it needs to (and doesn't take 10 minutes to install). The only thing that I'd like to see is Code Signing of the installer and the executables/binaries included but that requires someone higher up on the foodchain than me to do (perhaps we can finally get it when the D Foundation is in place).
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 23:34:21 UTC, Brad Anderson wrote: - It won't nuke the PATH environment variable due to a bug that was in NSIS (this was my first contribution to D years ago). Oh, that was you? Luckily I kept a copy of each path change, so it was easy to restore. I hope it didn't break too much for other people. :P
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 25 September 2015 at 22:17, Kagamin via Digitalmars-d wrote: > On Friday, 25 September 2015 at 09:03:35 UTC, John Colvin wrote: >> >> Realistically, no-one except an experienced full-time windows developer is >> ever going to get this right. > > > It's not a simple tradeoff: Manu's usual requirement is that dmd must work > at the utmost ease of use even if heavens crash. Correct behavior is > possible, but the question is how much user experience he would like to > sacrifice for correctness. This is because I am constantly introducing new users to D, and even more important when those users are colleagues in my workplace. If I talk about how cool D is, then point them at the website where they proceed to download and install the compiler, and their experience is immediately hindered by difficulty to configure within seconds of exposure, this paints a bad first impression, and frustratingly, it also reflects badly on *me* for recommending it; they're mostly convinced I'm some ridiculous fanboy (they're probably right). This is based exclusively on their experience and first-impressions. These basic things really matter! Understand; people with no vested interest in D, and likely some long-term resistance to every new trend in the software world jumping up and down fighting for their attention (which includes fanboys like me!), will not be impressed unless the experience is efficient and relatively seamless. I'm talking about appealing to potential end-users, not enthusiasts. My experience is, over and over again, for years now, that these tiny little things **REALLY MATTER**, more than literally anything else. If they're turned away by first impressions, then literally nothing else matters, and you rarely get a second chance; people don't tend to revisit something they've written off in the past.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 26 September 2015 at 02:06, Dicebot via Digitalmars-d 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. Renaming optlink to optlink.exe would have solved one problem in this case. > Taking your example, installing 3 versions of gcc simultaneously is not that > problematic if you don't need them all to be called `gcc`. Yeah, GCC has strategy here, toolchains all have a prefix that distinguishes them.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 26 September 2015 at 02:30, Jonathan M Davis via Digitalmars-d wrote: > 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. I think the biggest problem with PATH in windows in general is that windows doesn't have dependency management. As a result, every time you ship a program in windows, you need to bundle it together with every other program it depends on. This leads to hundreds of instances of exactly the same thing littered all over the place, and as soon as more than one of those places enters the PATH environment, then you have potential conflicts, and ordering issues. Windows is just a terrible operating system and I wish it would die already, but OSS just can't get a reasonable Microsoft Office, Photoshop, or Visual Studio alternative together. I don't even care if it's free, I'd pay good money for a linux version of each of these programs, they just have to exist.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/25/2015 6:03 AM, Dicebot wrote: Hm, so is the correct approach on Windows to provide separate shell for each application that has console utilities? X_x VS 10 does that, and I find it highly annoying. It sets a zillion environment variables that I have no idea what they are for or what they do. Evidently, this is the modern way, though I find it very unfriendly. DMC++ is designed to work without any environment variables at all. (It uses sc.ini to find where things are.) It was the only compiler of its day that did not require any installation, it would run off of the CD. The real problem is that DMD for Win64 requires some VS components. With every new release of VS, Microsoft throws every library and executable at a dart board and moves them to those random new directories. But I also do not understand why professional developers have such a hard time understanding what PATH is and apparently have no idea where the libraries exist on their system or how to find out where they are.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/25/2015 6:39 PM, Manu via Digitalmars-d wrote: Renaming optlink to optlink.exe would have solved one problem in this case. Renaming it where? Your posts are always tantalizing in that they leave out just enough information to ensure I can do nothing to help :-(
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 26 September 2015 at 09:15, Brad Anderson via Digitalmars-d 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. >> >> Then I try and build with LDC, it can't link anymore because paths are >> messed up and when looking for link.exe (microsoft's linker) it finds >> optlink link.exe instead. >> I tried to use a tool in VisualD which disassembles some code, but it >> can't find the tools it needs to do the job! >> >> This is silly. I don't know how such simple things can be so consistently >> hard?! >> My first and most frequent problems with the D ecosystem were pathing >> issues, and that's still more-or-less the case today. >> >> It's been 6 years for me. I'm getting tired. Can we please make an effort >> to get the paths right? This might mean some intelligence is required to >> make it work; check if the tool is the right tool? If it's not, keep >> looking? If tools can't be found, produce a dialog box prompting the user to >> supply the proper path to the tool? MSVC interaction (DMD-COFF and LDC) >> should probably leverage Microsoft's command line scripts, which are located >> in reliable places, and work reliably. MSCV associated tools shouldn't be >> capable of finding optlink by mistake. >> >> As a rule, no tool should ever require a windows user to interact with >> their path variable. It's a colossal mess, windows doesn't do 'PATH'. Mine >> has an endless list of bin directories, and many/most of them provide >> duplicates of the same programs. A robust program can never rely on PATH. >> >> [snip] >> >> This is minimal compared to my home dev environment (ie, is a >> controlled office PC). >> Surely this is evidence enough to conclude that no tool should *EVER* >> refer to PATH to find tools? > > > dmd, as it is installed, doesn't. The installer does detect and set the > direct paths for all of the Visual C integration with sc.ini. It uses the > values set by Visual C in the Windows registry. It's designed to be idiot > proof. It doesn't touch the system/user PATH environment variable for this > purpose (just the PATH dmd itself uses). The installer can optionally update > the PATH to add dmd (years ago I also added a Visual C Command Window style > shortcut to the installer for users that didn't want to change their PATH). > > Take a look at the current sc.ini[1]. It describes how it all works. You > never have to change your system/user PATH to get anything to work. Yeah, I think the only one of my complaints in this case that affected the DMD installer was the uninstallation issue. It looks like Rainer may have recently fixed this, which is great. >> The installer should remember where it installed last time! > > > I just use the defaults so I've never bothered to implement this. Pull > requests welcome, of course. Sounds trivial. > >> This requires action from every tool in the ecosystem, to include a little >> bit of logic that allows it to validate that paths are configured correctly >> and that the program _works_, and do something useful or ideally *helpful* >> if they're not. > > > Perhaps there are problems in LDC and VisualD but vanilla dmd has been > pretty solid in this area for awhile now. Rainer just recently added support > for VS2015. I'm not sure if it's in the latest release. > > Perhaps you could share your sc.ini and some more information about the > uninstall error you hit. It's kind of difficult to fix any bugs when the > description is vague and you seem to be the only one experiencing it. > > 1. > https://github.com/D-Programming-Language/dmd/blob/master/ini/windows/bin/sc.ini#L31 My sc.ini is whatever the installer wrote. It works, and it's uneventful. DMD is working well for me for over a year or so, uninstallation issue aside. I have come to find DMD reliable in recent years. I think LDC is the most important toolchain moving forward though, and that needs all the love it can get. I wonder if the DMD installer could be repurposed for LDC to use too? The path wrangling would be equally useful to LDC I think, since it depends on MSVC too.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/25/2015 8:23 PM, Walter Bright wrote: On 9/25/2015 6:39 PM, Manu via Digitalmars-d wrote: Renaming optlink to optlink.exe would have solved one problem in this case. Renaming it where? Your posts are always tantalizing in that they leave out just enough information to ensure I can do nothing to help :-( Oh, I see, you mean rename the executable. https://issues.dlang.org/show_bug.cgi?id=15118 You can greatly help ease the problems you're having by filing bug reports like this for every last one of the usability issues you run into.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 26 September 2015 at 13:20, Walter Bright via Digitalmars-d wrote: > On 9/25/2015 6:03 AM, Dicebot wrote: >> >> Hm, so is the correct approach on Windows to provide separate shell for >> each >> application that has console utilities? X_x > > > VS 10 does that, and I find it highly annoying. It sets a zillion > environment variables that I have no idea what they are for or what they do. > Evidently, this is the modern way, though I find it very unfriendly. It's horrible, but the alternative is demonstrably worse. > DMC++ is designed to work without any environment variables at all. (It uses > sc.ini to find where things are.) It was the only compiler of its day that > did not require any installation, it would run off of the CD. Fwiw, DMD is working great these days. It's just that I mostly use LDC now. > The real problem is that DMD for Win64 requires some VS components. With > every new release of VS, Microsoft throws every library and executable at a > dart board and moves them to those random new directories. Yup, PITA, but DMD is doing well with this, and LDC needs the same attention. > But I also do not understand why professional developers have such a hard > time understanding what PATH is and apparently have no idea where the > libraries exist on their system or how to find out where they are. It's not that, as I've tried to convey so many times before, it's all about the impression it makes. Is it one of quality and reliability? People don't like having their working time wasted. The only way I can get people to take a look at D is as an opportunistic aside, where people might humor my endless ranting, check it out, and see if it appeals to them. It's never something that presents itself to them as a task they must do to get their job done, D is not that prolific. If they're speculatively trialing a new technology (especially since it's hyped), it has about 3 minutes to make a positive impression on them, and create a perception that it may make their working life easier and better, or at the very least, get them excited such that it retains their attention past 3 minutes and they pursue it further. This is a matter of human psychology, and has nothing to do with D itself other than the way in which it makes its first impressions on new users. I have no clear suggestions, other than this should be held high in consideration when thinking about strategy for D moving forward. Editing the path variable is one of the most unenjoyable and annoying things to do in windows. start -> settings -> system -> advanced system settings -> environment variables -> PATH -> note the stupid window that appears; a single-line text box created in 1995 (or earlier?), which barely lets you see a single path in a line that's probably a few kb long... whenever you touch it, you know you're likely breaking something on your system that currently works ;) People do it if they have to; in my current case, dev's MUST setup emscripten to build the web frontend, and they proceed to complain about how shit the toolchain experience is, but they are forced to use it regardless... nobody is forced to use D. They must find themselves actively drawn to use D. This is my experience over many years now. The toolchain and compiler are now more-or-less sufficiently stable that anyone writing code will have a good experience. I believe it's the little things that matter more than anything in 2015.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 26 September 2015 at 13:29, Walter Bright via Digitalmars-d wrote: > On 9/25/2015 8:23 PM, Walter Bright wrote: >> >> On 9/25/2015 6:39 PM, Manu via Digitalmars-d wrote: >>> >>> Renaming optlink to optlink.exe would have solved one problem in this >>> case. >> >> >> Renaming it where? >> >> Your posts are always tantalizing in that they leave out just enough >> information >> to ensure I can do nothing to help :-( > > > Oh, I see, you mean rename the executable. > >https://issues.dlang.org/show_bug.cgi?id=15118 Wow. Yeah, it never occurred to me that renaming a tool that has been around for 10s of years was a reasonable thing to expect ;) Incidentally, I have encountered the same problem with the make.exe in the dmd/bin. It seems to be non-standard. > You can greatly help ease the problems you're having by filing bug reports > like this for every last one of the usability issues you run into. I did file each one yesterday as I encountered these problems. My post was about something slightly different though, I just want to try and bring it to attention again that the little things matter more than the attention they tend to get. I think it's important to realise that the ecosystem is taken in aggregate. DMD can do a great job of this stuff, but if LDC doesn't have the same love, it's 'D' in general that gets the blame. Out of curiosity, what is the strategy wrt LDC and GDC moving forward? Will they move towards simultaneous releases? Will they be included in CI builds, such that PR's which break (or don't work) the other compilers do fail CI? GDC as a culture has different packaging expectations so I don't think it's affected so much, but especially for Windows users LDC is the way forward, and it should be as solid as DMD in terms of presentation.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Saturday, 26 September 2015 at 01:37:57 UTC, Manu wrote: On 25 September 2015 at 22:17, Kagamin via Digitalmars-d wrote: [...] This is because I am constantly introducing new users to D, and even more important when those users are colleagues in my workplace. If I talk about how cool D is, then point them at the website where they proceed to download and install the compiler, and their experience is immediately hindered by difficulty to configure within seconds of exposure, this paints a bad first impression, and frustratingly, it also reflects badly on *me* for recommending it; they're mostly convinced I'm some ridiculous fanboy (they're probably right). This is based exclusively on their experience and first-impressions. These basic things really matter! Understand; people with no vested interest in D, and likely some long-term resistance to every new trend in the software world jumping up and down fighting for their attention (which includes fanboys like me!), will not be impressed unless the experience is efficient and relatively seamless. I'm talking about appealing to potential end-users, not enthusiasts. My experience is, over and over again, for years now, that these tiny little things **REALLY MATTER**, more than literally anything else. If they're turned away by first impressions, then literally nothing else matters, and you rarely get a second chance; people don't tend to revisit something they've written off in the past. They just don't care. This is what I think when I read this. If it's not the setup it would be something else. They would find something else to mask their uninterest. Human beings are talented at lying to themselves. They're just not honest enough with themselves, it's that simple. Don't be so gullible and try to understand what's behind the excuses !
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 26 September 2015 at 14:24, anon via Digitalmars-d wrote: > On Saturday, 26 September 2015 at 01:37:57 UTC, Manu wrote: >> >> On 25 September 2015 at 22:17, Kagamin via Digitalmars-d >> wrote: >>> >>> [...] >> >> >> This is because I am constantly introducing new users to D, and even >> more important when those users are colleagues in my workplace. >> If I talk about how cool D is, then point them at the website where >> they proceed to download and install the compiler, and their >> experience is immediately hindered by difficulty to configure within >> seconds of exposure, this paints a bad first impression, and >> frustratingly, it also reflects badly on *me* for recommending it; >> they're mostly convinced I'm some ridiculous fanboy (they're probably >> right). This is based exclusively on their experience and >> first-impressions. These basic things really matter! >> >> Understand; people with no vested interest in D, and likely some >> long-term resistance to every new trend in the software world jumping >> up and down fighting for their attention (which includes fanboys like >> me!), will not be impressed unless the experience is efficient and >> relatively seamless. >> I'm talking about appealing to potential end-users, not enthusiasts. >> My experience is, over and over again, for years now, that these tiny >> little things **REALLY MATTER**, more than literally anything else. If >> they're turned away by first impressions, then literally nothing else >> matters, and you rarely get a second chance; people don't tend to >> revisit something they've written off in the past. > > > They just don't care. This is what I think when I read this. If it's not the > setup it would be something else. They would find something else to mask > their uninterest. Human beings are talented at lying to themselves. > > They're just not honest enough with themselves, it's that simple. Don't be > so gullible and try to understand what's behind the excuses ! I don't think that's true at all. Humans are very susceptible to first impressions. It's all about presentation, getting them excited, and maintaining that excitement for some relatively short period of time, like, half an hour... as opposed to the first 3 minutes where it may have been rejected on initial contact. If people spend enough time that they start to feel invested, they're on the hook. In the case of D, they need to feel it's solid, and they need to feel cool and productive writing their first few lines. In my experience, it does well to have them perform some task that is a classic frustration in their 'native' language. For C++ users, I often get people to write 'static if', that's usually all it takes ;) What has proven to be very important to me, is that they be able to complete their first experimental task, whatever it is, painlessly, without ecosystem problems. I lost my boss at this step, because I suggested he look into vibe.d to do a simple webserver (websockets). He experienced problems, and it's practically impossible to debug exceptions (using VisualD, at the time), and that was enough to send him packing. If he did successfully complete that task, I'm certain my company would be using D today. I believe expanding the D user base in 2015 is mostly about psychology and advertising. D is pretty good technically these days.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/25/2015 9:07 PM, Manu via Digitalmars-d wrote: I did file each one yesterday as I encountered these problems. Ah, wonderful! My post was about something slightly different though, I just want to try and bring it to attention again that the little things matter more than the attention they tend to get. I think it's important to realise that the ecosystem is taken in aggregate. DMD can do a great job of this stuff, but if LDC doesn't have the same love, it's 'D' in general that gets the blame. I understand. Out of curiosity, what is the strategy wrt LDC and GDC moving forward? Will they move towards simultaneous releases? Will they be included in CI builds, such that PR's which break (or don't work) the other compilers do fail CI? GDC as a culture has different packaging expectations so I don't think it's affected so much, but especially for Windows users LDC is the way forward, and it should be as solid as DMD in terms of presentation. I'll leave that to the GDC and LDC teams.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/25/2015 8:55 PM, Manu via Digitalmars-d wrote: Editing the path variable is one of the most unenjoyable and annoying things to do in windows. start -> settings -> system -> advanced system settings -> environment variables -> PATH -> note the stupid window that appears; a single-line text box created in 1995 (or earlier?), which barely lets you see a single path in a line that's probably a few kb long... whenever you touch it, you know you're likely breaking something on your system that currently works ;) People do it if they have to; in my current case, dev's MUST setup emscripten to build the web frontend, and they proceed to complain about how shit the toolchain experience is, but they are forced to use it regardless... nobody is forced to use D. They must find themselves actively drawn to use D. You can edit sc.ini instead of PATH, as sc.ini overrides it. Anyhow, I edit the PATH from the path line like: PATH >foo.bat ... edit foo.bat and put SET in front of it... foo This is my experience over many years now. The toolchain and compiler are now more-or-less sufficiently stable that anyone writing code will have a good experience. I believe it's the little things that matter more than anything in 2015. Polish certainly matters a lot.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Saturday, 26 September 2015 at 05:35:04 UTC, Walter Bright wrote: Polish certainly matters a lot. Improving quality is an exponetial problem. After a while to reach the upper level requires a lot of work for almost none signifiant value added. The whole topic is absurd. It's not a problem for someone who's really interested to setup a few things, including writing one entry in the PATH. If that's perceived as a barrier then the person has probably nothing to do in the field.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 26 September 2015 at 15:17, Walter Bright via Digitalmars-d wrote: > On 9/25/2015 9:07 PM, Manu via Digitalmars-d wrote: >> >> I did file each one yesterday as I encountered these problems. > > > Ah, wonderful! > >> My post >> was about something slightly different though, I just want to try and >> bring it to attention again that the little things matter more than >> the attention they tend to get. >> I think it's important to realise that the ecosystem is taken in >> aggregate. DMD can do a great job of this stuff, but if LDC doesn't >> have the same love, it's 'D' in general that gets the blame. > > > I understand. > >> Out of curiosity, what is the strategy wrt LDC and GDC moving forward? >> Will they move towards simultaneous releases? Will they be included in >> CI builds, such that PR's which break (or don't work) the other >> compilers do fail CI? >> GDC as a culture has different packaging expectations so I don't think >> it's affected so much, but especially for Windows users LDC is the way >> forward, and it should be as solid as DMD in terms of presentation. > > > I'll leave that to the GDC and LDC teams. And right there is the problem as I see it, summarised in one sentence ;) If you take the D ecosystem as aggregate, these issues are just as much issues for the core dev team as they are for these couple of guys with a distinctly unfair burden. An example that comes to mind; I think one of the biggest technical problem in the D ecosystem right now is that LDC doesn't support CV8 debuginfo writing. You might be one of the world's most qualified experts on that, would you consider adapting that work to LLVM? Are GDC/LDC actively building against DMD head these days? I might be out of date, but that wasn't the case in the past. Last time I was current, they were updating periodically, and at great effort to adapt all the changes in the meantime that didn't consider their builds. Do we know what kind of time the GDC/LDC guys spend fixing up breakages like that? Would it be better to catch those breakages when the initial PR is accepted, rather than a wall of issues every now and then? If I had to guess, I'd say it looked like this is probably the reason for infrequent frontend updates, and the other compilers always being a couple of versions behind DMD, which is very toxic for the ecosystem. I might be completely wrong on that, but it looks that way.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
Am Fri, 25 Sep 2015 16:30:03 + schrieb Jonathan M Davis : > 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 IIRC the windows way is not using PATH if possible. Instead you can usually check if a program is installed and where using some registry keys.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 26 September 2015 at 15:35, Walter Bright via Digitalmars-d wrote: > On 9/25/2015 8:55 PM, Manu via Digitalmars-d wrote: >> >> Editing the path variable is one of the most unenjoyable and annoying >> things to do in windows. start -> settings -> system -> advanced >> system settings -> environment variables -> PATH -> note the stupid >> window that appears; a single-line text box created in 1995 (or >> earlier?), which barely lets you see a single path in a line that's >> probably a few kb long... whenever you touch it, you know you're >> likely breaking something on your system that currently works ;) >> People do it if they have to; in my current case, dev's MUST setup >> emscripten to build the web frontend, and they proceed to complain >> about how shit the toolchain experience is, but they are forced to use >> it regardless... nobody is forced to use D. They must find themselves >> actively drawn to use D. > > > You can edit sc.ini instead of PATH, as sc.ini overrides it. > > Anyhow, I edit the PATH from the path line like: > > PATH >foo.bat > > ... edit foo.bat and put SET in front of it... > > foo That kinda seems like more work... but whatever works for you ;) But regardless, I wasn't talking about DMD pathing troubles. The only DMD related issue I mentioned was the uninstaller failing. In the case I gave, LDC was finding the wrong linker. My claim is that it is wrong for tools to find their dependencies in PATH on windows. That should be a last resort in lieu of proper configuration, and proper configuration should have ideally happened during installation (as is the case with DMD).
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 26 September 2015 at 16:35, schweik via Digitalmars-d wrote: > On Saturday, 26 September 2015 at 05:35:04 UTC, Walter Bright wrote: >> >> Polish certainly matters a lot. > > > Improving quality is an exponetial problem. After a while to reach the upper > level requires a lot of work for almost none signifiant value added. False, the value is indeed subtle, but extremely powerful. I don't necessarily advocate there-were-10_000-QA-testers-banging-at-this-for-years 'perfect', but it has to work reliably, especially the first time, and without manual configuration. > The whole topic is absurd. It's not a problem for someone who's really > interested to setup a few things, including writing one entry in the PATH. > If that's perceived as a barrier then the person has probably nothing to do > in the field. I don't know where you work, but I've been working for almost 2 decades with hundreds of 'professional programmers'. They're not like OSS programmers. They don't really care about technology, they don't study it on the side, they don't read tech blogs, they don't keep up with the latest trends. They don't care, they just go to work from 9-5, they have a task list, and they need to strike items off that list and *anything* that is perceived as friction is written off almost immediately. They have firmly set habits formed over many years, and they're not interested in changing unless they can immediately perceive a significant benefit to their productivity. They're also averse to risk, so balancing that sense of risk requires a really encouraging first experience. These are of course gross generalisations, but I feel they are more-or-less accurate. This is how it is. At least in my neck of the woods. Obviously, this is way off topic and extends to far more than paths and configuring the tool, but it's just that this path thing is endlessly recurring, it seems like such a no brainer that this sort of thing should never fail and I kinda lost my shit. Your comment is based on the assumption that the user *wants* to use D (is "really interested"), or approaches it like some tool they must install and configure to complete their task. That's not the case. In 2015, users are almost entirely indifferent if not skeptical towards [new language here] (in this case, D), and likely fatigued by the background noise of shiny new technologies forced upon them, or otherwise fighting for their attention. They're effectively humoring me, allowing me an opportunity to prove their preconception wrong, and it had better be the case that nothing goes wrong during these few precarious minutes; every little thing is very damaging to impressions. Conversely, if it all goes smoothly and looks slick, it makes a very good impression... as if what I'm peddling might be true ;) My comments are anecdotes. I've been witnessing the exact same patterns, over and over and over for years. It's not that they want to hate D, it's that D has to make a valuable impression on them very quickly before they lose interest and get back to work. *I JUST WANT TO USE D PROFESSIONALLY* I don't like having my time wasted, and the amount of time that C++ wastes is... kinda painful to quantify. I want to enjoy my career, and I don't enjoy programming C++ anymore. At the same time, I can't seem to use D professionally for apparently trivial, almost intangible reasons. I think most D users understand this feeling well. Perhaps part of the problem is that the bar presented by C++ is fairly high? C/C++ is like, really established, and Visual Studio is pretty good. The quality of the compiler isn't very important; MSVC is so bad it's not funny! The most important things are that it 'just works'™ out of the box, the debugger MUST work well, F12 (go to definition) also works well, and autocomplete works most of the time. I can say with confidence that those things are all that my colleagues care about. They will test those features in the first 2 minutes, and if it doesn't work, they will stop. VisualD does pretty well, but we fail at debugging. I have advocated in my workplaces/community for years with varying degrees of success, but every single workplace anecdote I have has basically gone "colleagues heard my rants, got excited, tried it out briefly, fell down due to [insert whatever reason foiled this attempt]". And there is rarely a second chance. Are we making a tool for professional programmers, or is this community an intellectual hobby that attracts language nerds? We need to learn how to impress well on working professionals, in the few moments that we get to do so; typically just a couple of minutes. I'm driving my company's tech towards a completely language agnostic platform, where components may pick and choose between suitable languages for specific tasks. I'll have another good go at a sell for D at that point since it's further matured since my last attempt a year ago. It will almost definitely be another failure because LDC doesn't suppo
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 2015-09-26 05:08, Manu via Digitalmars-d wrote: Windows is just a terrible operating system and I wish it would die already, but OSS just can't get a reasonable Microsoft Office, Photoshop, or Visual Studio alternative together. I don't even care if it's free, I'd pay good money for a linux version of each of these programs, they just have to exist. Photoshop and Microsoft Office are available on OS X. Visual Studio Code is also available on OS X, although not the same as the regular Visual Studio, I have no experience how they compare. On OS X there's also Pixelmator as an alternative to Photoshop. I've heard it's pretty good but I'm not experienced in this area so can't really say if it's a viable option. Sure OS X is not Linux, but it's a Unix system. Better than nothing :) -- /Jacob Carlborg
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 2015-09-26 11:50, Manu via Digitalmars-d wrote: *anything* that is perceived as friction is written off almost immediately. Yet they still use C++ :) -- /Jacob Carlborg
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Saturday, 26 September 2015 at 10:14:38 UTC, Jacob Carlborg wrote: On 2015-09-26 11:50, Manu via Digitalmars-d wrote: *anything* that is perceived as friction is written off almost immediately. Yet they still use C++ :) C++ has its issues, but it's still a great language - especially in comparison to many other languages. And even if the programmer in question really doesn't like C++ that much, they're at least familiar with it and used to dealing with its downsides. Using a new language takes them completely outside their comfort zone and requires them to deal with a different set of pros and cons, and it requires them to learn a new a language, which meany programmers just don't want to deal with. So, if a new language seems to have problems that they're current one doesn't (even if it supposedly has other aspects which are way better), many folks simply aren't going to be interested. It's a risk to try something new, and it takes time. And many folks simply don't want to do that. You tend get similar problems when trying to get someone to use any program that replaces something that they're currently using (trying to get someone to switch to LibreOffice or to Linux would be good examples of that). Unfortunately, with the kinds of folks that we're talking about here, you need to get pretty much _everything_ right in order to not run into problems like Manu is talking about. It tends to take almost nothing for someone to decide that trying something out isn't worth it if they're not actively looking for something better. So, while we have a lot to gain by improving the out-of-the-box user experience for D, it's also a fight that we can't really ever win. There's always going to be _something_ which makes it seem like too much friction to many folks. But if we can do better, then at least that will make it so that fewer people react so negatively, even if many (or even most) still will. I don't think that there's any question that we have an easier time of convincing someone who's actually interested in finding something better and actually giving D a shot than someone who's simply trying it out and dismiss it if they can. And it sounds like Manu is dealing a lot with the latter type of folks. - Jonathan M Davis
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/26/2015 1:21 AM, Manu via Digitalmars-d wrote: I'll leave that to the GDC and LDC teams. And right there is the problem as I see it, summarised in one sentence ;) If you take the D ecosystem as aggregate, these issues are just as much issues for the core dev team as they are for these couple of guys with a distinctly unfair burden. Everything is unfair, but the idea behind having 3 compilers is there is no one right way to make a compiler. Me telling the LDC and GDC teams what to do and trying to be their manager is inappropriate. An example that comes to mind; I think one of the biggest technical problem in the D ecosystem right now is that LDC doesn't support CV8 debuginfo writing. You might be one of the world's most qualified experts on that, would you consider adapting that work to LLVM? The CV8 support in DMD is open source and the format of the CV8 records is readily apparent by reading that source code. There's nothing magical about it. It's about a thousand lines of code. https://github.com/D-Programming-Language/dmd/blob/master/src/backend/cv8.c But you're asking me to become an expert on LLVM internals, which is a lot harder. I'm flattered that you believe I am such a superman I can do leading edge work on three totally different modern compilers simultaneously, and work on the language design, run D conferences, do presentations on D, help people with the daily emails asking for help, write articles, etc. But I assure you I am not that good. Oh, and I'm asked to write an IDE, too. I got a sincere proposal yesterday that I write a gui D debugger. I suppose I could do that before lunch tomorrow!
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Saturday, 26 September 2015 at 09:51:19 UTC, Manu wrote: Are we making a tool for professional programmers, or is this community an intellectual hobby that attracts language nerds? We need to learn how to impress well on working professionals, in the few moments that we get to do so; typically just a couple of minutes. Professional programmers pay for their tools, is anybody here paying? D is not going to have the polish to attract them because it's a small OSS project, without the funding llvm/clang gets from Apple or all the consulting/hardware companies who chip in to gcc. I'd advise to go the Facebook route and try to get D used for some dev tools here and there, especially on the server, like Warp. Being easy for desktop devs is never going to happen without some company like Apple putting more polish on the tools and building an IDE around it, like they once did around gcc and now do around clang/llvm. You're wasting your time if you think you're going to get that from an OSS project that has no associated business model, like llvm/clang/Xcode does.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Saturday, 26 September 2015 at 09:51:19 UTC, Manu wrote: On 26 September 2015 at 16:35, schweik via Digitalmars-d wrote: On Saturday, 26 September 2015 at 05:35:04 UTC, Walter Bright wrote: Polish certainly matters a lot. Improving quality is an exponetial problem. After a while to reach the upper level requires a lot of work for almost none signifiant value added. False, the value is indeed subtle, but extremely powerful. I don't necessarily advocate there-were-10_000-QA-testers-banging-at-this-for-years 'perfect', but it has to work reliably, especially the first time, and without manual configuration. Generally true but here we are talking about setting-up a compiler. Maybe a perfect setup could open the door to more new users but those who would gave up in front of the configuration problem will give up anyway because of the problems inherent to programming. The PATH thing is just a joke compared to the mountain a new user has to climb. I really think that currently there is no problem. Just download the zip, unpack it and put the 'dmd\bin' folder to the PATH...when a new version is released rename the previous dmd folder and unpack the new dmd folder to the same location, and so on. It just works.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 09/26/15 13:10, Walter Bright via Digitalmars-d wrote: > On 9/26/2015 1:21 AM, Manu via Digitalmars-d wrote: >>> I'll leave that to the GDC and LDC teams. >> >> And right there is the problem as I see it, summarised in one sentence ;) >> >> If you take the D ecosystem as aggregate, these issues are just as >> much issues for the core dev team as they are for these couple of guys >> with a distinctly unfair burden. > > Everything is unfair, but the idea behind having 3 compilers is there is no > one right way to make a compiler. Me telling the LDC and GDC teams what to do > and trying to be their manager is inappropriate. I'm pretty sure what was meant was more (tri-directional) coordination, not management. > The CV8 support in DMD is open source and the format of the CV8 records is > readily apparent by reading that source code. There's nothing magical about > it. It's about a thousand lines of code. > > https://github.com/D-Programming-Language/dmd/blob/master/src/backend/cv8.c Given the DMD licensing situation, nobody will (or should) even look inside the DMD repo for info. Especially that "backend" string is really scary. I decided to blindly trust your words above, and, with trembling hands, somehow managed to click that link. Phew. That file really appears to be boost licensed. > I'm flattered that you believe I am such a superman I can do leading edge > work on three totally different modern compilers simultaneously, and work on > the language design, run D conferences, do presentations on D, help people > with the daily emails asking for help, write articles, etc. But I assure you > I am not that good. Oh, and I'm asked to write an IDE, too. I got a sincere > proposal yesterday that I write a gui D debugger. I suppose I could do that > before lunch tomorrow! The one thing that you, and only you, can do is to make the available free parts accessible, for example by publishing a git repo with them, but w/o any non-open-source code. Nobody else can do that (ie the result wouldn't be sufficiently trustworthy). Open source code hidden somewhere deep inside a non-free compiler implementation might just as well not exist, as noone interested will be willing to look for it there. artur
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 26 Sep 2015 4:31 pm, "Artur Skawina via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > On 09/26/15 13:10, Walter Bright via Digitalmars-d wrote: > > On 9/26/2015 1:21 AM, Manu via Digitalmars-d wrote: > >>> I'll leave that to the GDC and LDC teams. > >> > >> And right there is the problem as I see it, summarised in one sentence ;) > >> > >> If you take the D ecosystem as aggregate, these issues are just as > >> much issues for the core dev team as they are for these couple of guys > >> with a distinctly unfair burden. > > > > Everything is unfair, but the idea behind having 3 compilers is there is no one right way to make a compiler. Me telling the LDC and GDC teams what to do and trying to be their manager is inappropriate. > > I'm pretty sure what was meant was more (tri-directional) coordination, > not management. > The only coordination in place is that upstream DMD codebase must never break GDC or LDC's ability to build it and pass the testsuite. For the time being this is enough. As for common codebase, we are in a state of divulging further apart for the first time in a while, but I don't see it as my role to keep tabs on every change upstream does. And there are already some horrible things that need sorting out (or that need reapplying because they've vanished in the D implementation) but not worth my efforts until it comes to switching proper. Iain.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Saturday, 26 September 2015 at 15:01:06 UTC, Iain Buclaw wrote: For the time being this is enough. As for common codebase, we are in a state of divulging further apart for the first time in a while, […] I think it's quite the contrary for LDC. We are releasing a 2.067-based version soon, just started testing the 2.068.2 merge, and will hopefully have a DDMD-based version by late October. — David
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Saturday, 26 September 2015 at 03:55:50 UTC, Manu wrote: [snip] Editing the path variable is one of the most unenjoyable and annoying things to do in windows. start -> settings -> system -> advanced system settings -> environment variables -> PATH -> note the stupid window that appears; a single-line text box created in 1995 (or earlier?), which barely lets you see a single path in a line that's probably a few kb long... whenever you touch it, you know you're likely breaking something on your system that currently works ;) People do it if they have to; in my current case, dev's MUST setup emscripten to build the web frontend, and they proceed to complain about how shit the toolchain experience is, but they are forced to use it regardless... nobody is forced to use D. They must find themselves actively drawn to use D. Just a little aside tip, Windows search these days is actually really excellent for settings like this (and programs). Windows Key + "env" + Enter is enough to get you to the dialog. I completely agree that you should almost never have to do this though.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Saturday, 26 September 2015 at 14:31:15 UTC, Artur Skawina wrote: Given the DMD licensing situation, nobody will (or should) even look inside the DMD repo for info. Especially that "backend" string is really scary. I decided to blindly trust your words above, and, with trembling hands, somehow managed to click that link. Phew. That file really appears to be boost licensed. ...> Open source code hidden somewhere deep inside a non-free compiler implementation might just as well not exist, as noone interested will be willing to look for it there. out of curiosity, what is your concern? as I understand it you can produce derived works but the restriction is on redistribution of the compiler, and if you care about that you ask Walter and he says yes.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Saturday, 26 September 2015 at 10:02:46 UTC, Jacob Carlborg wrote: On 2015-09-26 05:08, Manu via Digitalmars-d wrote: Windows is just a terrible operating system and I wish it would die already, but OSS just can't get a reasonable Microsoft Office, Photoshop, or Visual Studio alternative together. I don't even care if it's free, I'd pay good money for a linux version of each of these programs, they just have to exist. Photoshop and Microsoft Office are available on OS X. Visual Studio Code is also available on OS X, although not the same as the regular Visual Studio, I have no experience how they compare. I tried visual studio code and it sucks - it is nothing but a text editor, a notepad with syntax highlighting like sublime only much worse ;) --Stephan
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Saturday, 26 September 2015 at 19:22:16 UTC, Laeeth Isharc wrote: On Saturday, 26 September 2015 at 14:31:15 UTC, Artur Skawina wrote: Given the DMD licensing situation, nobody will (or should) even look inside the DMD repo for info. Especially that "backend" string is really scary. I decided to blindly trust your words above, and, with trembling hands, somehow managed to click that link. Phew. That file really appears to be boost licensed. ...> Open source code hidden somewhere deep inside a non-free compiler implementation might just as well not exist, as noone interested will be willing to look for it there. out of curiosity, what is your concern? as I understand it you can produce derived works but the restriction is on redistribution of the compiler, and if you care about that you ask Walter and he says yes. Those who have had to deal with copyright lawyers become paranoid: ;) http://forum.dlang.org/post/mailman.2659.1403347797.2907.digitalmar...@puremagic.com http://forum.dlang.org/post/dmfr07$2u3u$1...@digitaldaemon.com http://forum.dlang.org/post/euuvum$171f$1...@digitalmars.com
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/26/2015 7:24 AM, Artur Skawina via Digitalmars-d wrote: Given the DMD licensing situation, nobody will (or should) even look inside the DMD repo for info. Especially that "backend" string is really scary. I decided to blindly trust your words above, and, with trembling hands, somehow managed to click that link. Phew. That file really appears to be boost licensed. Even if cv8.c was locked up tight with licensing, the CV8 file format itself would not be covered by such license. CV8 is not a Digital Mars file format, it's a Microsoft format. Now, if Microsoft decided to assert some sort of IP control over the CV8 format in order to prevent LLVM from generating CV8 format, whether I implemented CV8 in LLVM or the LLVM did would make no difference. I have no authority over Microsoft licensing issues and don't speak for Microsoft on them.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/26/2015 8:04 AM, David Nadlinger wrote: On Saturday, 26 September 2015 at 15:01:06 UTC, Iain Buclaw wrote: For the time being this is enough. As for common codebase, we are in a state of divulging further apart for the first time in a while, […] I think it's quite the contrary for LDC. We are releasing a 2.067-based version soon, just started testing the 2.068.2 merge, and will hopefully have a DDMD-based version by late October. Pretty dazz!
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Saturday, 26 September 2015 at 20:09:54 UTC, Joakim wrote: On Saturday, 26 September 2015 at 19:22:16 UTC, Laeeth Isharc wrote: On Saturday, 26 September 2015 at 14:31:15 UTC, Artur Skawina wrote: Given the DMD licensing situation, nobody will (or should) even look inside the DMD repo for info. Especially that "backend" string is really scary. I decided to blindly trust your words above, and, with trembling hands, somehow managed to click that link. Phew. That file really appears to be boost licensed. ...> Open source code hidden somewhere deep inside a non-free compiler implementation might just as well not exist, as noone interested will be willing to look for it there. out of curiosity, what is your concern? as I understand it you can produce derived works but the restriction is on redistribution of the compiler, and if you care about that you ask Walter and he says yes. Those who have had to deal with copyright lawyers become paranoid: ;) http://forum.dlang.org/post/mailman.2659.1403347797.2907.digitalmar...@puremagic.com http://forum.dlang.org/post/dmfr07$2u3u$1...@digitaldaemon.com http://forum.dlang.org/post/euuvum$171f$1...@digitalmars.com well, okay, but the posts from Walter you link to are from more then eight years ago, and he spoke about how he was beginning to open source parts of Phobos (when D's status was rather different). anything is possible. but so long as Walter is with us and in control of Digital Mars, I really don't see that it is possible for Digital Mars to sue someone who has looked at the code, been inspired by it, and done something short of straight ripping it off wholesale. because there's much more at stake with D, and it wouldn't make any sense. it's not a company with the resources let alone interest to play games with trivial lawsuits, is my guess. the contract nitty gritty only practically comes into play in the unpleasant scenario that Walter should not be in control of Digital Mars at some point in some decades, and I trust he has made provision for that. (Walter?) Artur makes a very strong statement that doesn't make any sense to me (and I have certainly had at least my share of silly games with contracts): Given the DMD licensing situation, __nobody__ will (or should) even look inside the DMD repo for info. Especially that He's entitled to his view, but normally one is taken more seriously if one makes a reasoned argument for a strong view (which he declined to do in that previous thread). Prudence is a virtue, but it's not quite the same thing as blanket aversion to all possible risks - each must judge for himself, but advising others like this goes quite far.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 09/26/15 23:58, Laeeth Isharc via Digitalmars-d wrote: >> Given the DMD licensing situation, __nobody__ will (or should) even look >> inside the DMD repo for info. Especially that Note that the above is not what I actually wrote, but has been altered with no mention of this fact. It's hard enough to convey tone via email; such manipulations don't help. > He's entitled to his view, but normally one is taken more seriously if one > makes a reasoned argument for a strong view (which he declined to do in that > previous thread). Prudence is a virtue, but it's not quite the same thing as > blanket aversion to all possible risks - each must judge for himself, but > advising others like this goes quite far. It's not advice, but a statement of fact. Well, the `(or should)` part /is/, but it was parenthesized for a reason - it's not the main point, but only a preemptive response to any potential "but they should" reply. Obviously, "nobody" in this context does not literally mean "nobody", but nobody from the set of people with an interest in the subject that might potentially create open source or otherwise differently licensed works. The latter subset can in theory be the same as the whole set (it will be smaller in practice, yes). Considering that this discussion is about an apparently undocumented file format that Manu would like to see supported in a differently licensed work (LLVM) and thinks that Walter and/or DMD is a good, or even unique, source for info about, then yes -- _nobody_ (that would like to use the information to indirectly incorporate in into LLVM) will look for it inside some other proprietary compiler. At least, they are _not_supposed_to_, and really shouldn't. Even without malicious intent it's too easy for the result to be similar enough that somebody can claim it's a derivative work. And even when such a claim is obviously bogus, you do not want to have to deal with it. Hence, as it appears that the code in question is boost licensed, (re-)publishing it in a way that would limit the "contamination" concerns might help Manu's cause, and does not require Walter do much more than a git clone+add+commit+push. Convincing a LLVM developer to support a file format that's documented in a single boost licensed file is going to be much easier than suggesting that they obtain the info from a non-free non-redistributable compiler source from another vendor. And by "much easier" I mean "possible", because the other option simply isn't (and shouldn't). Now, I don't know if the info in that file really is as unique as Manu says, plus because of this thread it already became much more accessible, so it's possible that the issue has been already solved. But every other `free-but-entangled-with-non-free` part of DMD has the same problem. "Let's look inside works we can't legally use, just in case there's some usable part inside" is not a viable option. Really. artur
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Saturday, 26 September 2015 at 23:48:05 UTC, Artur Skawina wrote: On 09/26/15 23:58, Laeeth Isharc via Digitalmars-d wrote: Given the DMD licensing situation, __nobody__ will (or should) even look inside the DMD repo for info. Especially that Note that the above is not what I actually wrote, but has been altered > with no mention of this fact. It's hard enough to convey tone via email; such manipulations don't help. I added __ __ around nobody to make it clear what I was referring to. Do you have a better idea about how to economically highlight things when using a newsgroup interface? It would have been appropriate to mention my emphasis, and mea culpa for that. But when you say altered it suggests deliberate misrepresentation in a way that fundamentally mischaracterises what you wrote, and I don't believe this is the case. I merely highlighted it, and I acknowledge that this might be misunderstood by somebody reading in a hurry. He's entitled to his view, but normally one is taken more seriously if one makes a reasoned argument for a strong view (which he declined to do in that previous thread). Prudence is a virtue, but it's not quite the same thing as blanket aversion to all possible risks - each must judge for himself, but advising others like this goes quite far. It's not advice, but a statement of fact. Well, the `(or should)` part /is/, but it was parenthesized for a reason - it's not the main point, but only a preemptive response to any potential "but they should" reply. Well, okay, I see where you are coming from. But there's enough of this idea already that dmd isn't "free" in a way that seriously matters and that reflects a spirit that wouldn't like it to be free if commercial things were different that perhaps you can see why what you wrote might also be taken a certain way in this context. Words have power, and it's easy to forget that when writing from a personal perspective. (We're all part of the problem in 2015, me too). Obviously, "nobody" in this context does not literally mean "nobody", > but nobody from the set of people with an interest in the subject that might potentially create open source or otherwise differently licensed works. The latter subset can in theory be the same as the whole set (it will be smaller in practice, yes). "Obviously in this context does not literally mean "nobody", Yes, well, context isn't always very clear in this medium, and neither is what's obvious. That's a very big set! I would have thought the set of people practically speaking is those that work on open-source or closed-source compiler backends. That's much smaller than implied by what you wrote. Also, the set of people with an interest in things vastly exceeds the number who do any work in the area. Considering that this discussion is about an apparently undocumented file format that Manu would like to see supported in a differently licensed work (LLVM) and thinks that Walter and/or DMD is a good, or even unique, source for info about, then > yes -- _nobody_ (that would like to use the information to indirectly > incorporate in into LLVM) will look for it inside some other proprietary > compiler. At least, they are _not_supposed_to_, and really shouldn't. Even without malicious intent it's too easy for the result to be similar enough that somebody can claim it's a derivative work. I see your point that given the need for not just propriety, but the appearance of it then if someone were an LLVM contributor or serious potential contributor it would be best to do as Manu suggested and ask Walter than just look at the source without knowing its status. I guess it's not so applicable, but you couldn't have known that before looking. But then, if one's concern is primarily about legal risks, then announcing one is looking at code and making a big deal about one's concerns is hardly prudent either as a general strategy. (And if it's an internal ethical concern that's between you and whatever you do or don't believe in). Hence, as it appears that the code in question is boost licensed, (re-)publishing it in a way that would limit the "contamination" concerns might help Manu's cause, and does not require Walter do much more than a git clone+add+commit+push. Convincing a LLVM developer to support a file format that's documented in a single boost licensed file is going to be much easier than suggesting that they obtain the info from a non-free non-redistributable compiler source from another vendor. And by "much easier" I mean "possible", because the other option simply isn't (and shouldn't). As I understand it, it's redistributable if you just ask nicely and promise not to sue the various people involved. My reading of what Walter has said on Reddit is that you could base a commercial compiler on dmd and sell it and he would be fine with that. But perhaps th
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Saturday, 26 September 2015 at 23:48:05 UTC, Artur Skawina wrote: "Let's look inside works we can't legally use, just in case there's some usable part inside" is not a viable option. Really. You have one team take a look at it to help them document the file format, then a separate team use that file format documentation to write an alternate implementation. Then it is aiding in reverse engineering the file format instead of creating a derivative work of the implementation, as long as the two teams don't communicate outside that file format spec doc.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/26/2015 10:20 AM, Brad Anderson wrote: Just a little aside tip, Windows search these days is actually really excellent for settings like this (and programs). Windows Key + "env" + Enter is enough to get you to the dialog. Sorry, but the env dialog box is a sad joke, at least on Windows 7. 1. You cannot select any of the text in the dialog. 2. You cannot increase the size of the dialog. 3. Longer values end in "...". 4. You cannot edit so-called "System" environment variables. 5. You can scroll the list up or down, but not sideways! That all conspires to ensure that you CANNOT SEE what the longer values even are! It's pathetic. Back to the command line for me.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Sunday, 27 September 2015 at 06:34:29 UTC, Walter Bright wrote: On 9/26/2015 10:20 AM, Brad Anderson wrote: Just a little aside tip, Windows search these days is actually really excellent for settings like this (and programs). Windows Key + "env" + Enter is enough to get you to the dialog. Sorry, but the env dialog box is a sad joke, at least on Windows 7. 1. You cannot select any of the text in the dialog. 2. You cannot increase the size of the dialog. 3. Longer values end in "...". 4. You cannot edit so-called "System" environment variables. 5. You can scroll the list up or down, but not sideways! That all conspires to ensure that you CANNOT SEE what the longer values even are! It's pathetic. Back to the command line for me. I think that the only aspect of it which has changed since Windows 95 is the window style. Whenever I have to edit PATH, I copy it out of their horrible edit box, edit it in something like vim, and then copy it back. Honestly, MS should be embarrassed by the state of the env dialog box. - Jonathan M Davis
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 27 September 2015 at 16:52, Jonathan M Davis via Digitalmars-d wrote: > On Sunday, 27 September 2015 at 06:34:29 UTC, Walter Bright wrote: >> >> On 9/26/2015 10:20 AM, Brad Anderson wrote: >>> >>> Just a little aside tip, Windows search these days is actually really >>> excellent >>> for settings like this (and programs). Windows Key + "env" + Enter is >>> enough to >>> get you to the dialog. >> >> >> Sorry, but the env dialog box is a sad joke, at least on Windows 7. >> >> 1. You cannot select any of the text in the dialog. >> 2. You cannot increase the size of the dialog. >> 3. Longer values end in "...". >> 4. You cannot edit so-called "System" environment variables. >> 5. You can scroll the list up or down, but not sideways! >> >> That all conspires to ensure that you CANNOT SEE what the longer values >> even are! It's pathetic. >> >> Back to the command line for me. > > > I think that the only aspect of it which has changed since Windows 95 is the > window style. Whenever I have to edit PATH, I copy it out of their horrible > edit box, edit it in something like vim, and then copy it back. Honestly, MS > should be embarrassed by the state of the env dialog box. > > - Jonathan M Davis They simply don't recognise its existence. It's a piece of antiquated detritus, only used by strange people who wear woolen shirts pretending to be *nix users while using windows ;)
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 2015-09-26 21:30, extrawurst wrote: I tried visual studio code and it sucks - it is nothing but a text editor, a notepad with syntax highlighting like sublime only much worse ;) I guess that depends on for which languages. For C# it supports accurate intellisense, refactoring, debugging and other features. I have not tried that myself so it could of course be a big fat lie. -- /Jacob Carlborg
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 27 September 2015 at 19:26, Jacob Carlborg via Digitalmars-d wrote: > On 2015-09-26 21:30, extrawurst wrote: > >> I tried visual studio code and it sucks - it is nothing but a text >> editor, a notepad with syntax highlighting like sublime only much worse ;) > > > I guess that depends on for which languages. For C# it supports accurate > intellisense, refactoring, debugging and other features. I have not tried > that myself so it could of course be a big fat lie. Comprehensive plugin support is on the short-list apparently, and that specifically includes support for plugging in language services, build systems and debuggers. I think it'll be a good editor in another year or 2. It's just nice that a piece of linux software has corporate backing!
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/27/2015 12:54 AM, Manu via Digitalmars-d wrote: They simply don't recognise its existence. It's a piece of antiquated detritus, only used by strange people who wear woolen shirts pretending to be *nix users while using windows ;) ?? Visual Studio sets all these environment variables, in addition to the usual blizzard set by Microsoft Windows and other Microsoft programs: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>set Framework35Version=v3.5 FrameworkDir=C:\Windows\Microsoft.NET\Framework64 FrameworkDIR64=C:\Windows\Microsoft.NET\Framework64 FrameworkVersion=v4.0.30319 FrameworkVersion64=v4.0.30319 FSHARPINSTALLDIR=C:\Program Files (x86)\Microsoft F#\v4.0\ INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE;C:\Program Files (x86)\Micros oft Visual Studio 10.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include ; LIB=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\LIB\amd64;C:\Program Files (x86)\Microsof t Visual Studio 10.0\VC\ATLMFC\LIB\amd64;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\lib\x64 ; LIBPATH=C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Windows\Microsoft.NET\Framework64\v3.5;C: \Program Files (x86)\Microsoft Visual Studio 10.0\VC\LIB\amd64;C:\Program Files (x86)\Microsoft Visu al Studio 10.0\VC\ATLMFC\LIB\amd64; Path=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64;C:\Windows\Microsoft.NET\Frame work64\v4.0.30319;C:\Windows\Microsoft.NET\Framework64\v3.5;C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\VCPackages;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools;C:\Program Files (x86)\HTML Help Workshop;C: \Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\x64;C:\Program Files (x86)\Mic rosoft SDKs\Windows\v7.0A\bin\x64;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shar ed\Windows Live;C:\W indows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\; C:\Program Files\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\DTS\ Binn\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files (x86)\Windows Live\Sha red;C:\Program Files (x86)\Skype\Phone\ PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC Platform=X64 VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\ VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\ WindowsSdkDir=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 28 September 2015 at 09:51, Walter Bright via Digitalmars-d wrote: > On 9/27/2015 12:54 AM, Manu via Digitalmars-d wrote: >> >> They simply don't recognise its existence. It's a piece of antiquated >> detritus, only used by strange people who wear woolen shirts >> pretending to be *nix users while using windows ;) > > > ?? Visual Studio sets all these environment variables, in addition to the > usual blizzard set by Microsoft Windows and other Microsoft programs: > > [...] Huh? We're talking about the environment dialog box right... or so I though? Maybe you're objecting with the suggestion that normal users really do actively use environment variables? If so, your example refers to auto-configured stuff that's completely invisible to average users, as it should be in windows. I've never used the VS command prompt in almost 20 years. Not once. It's only linux ports that require you to mess with the environment in windows. MS would never require that of a user.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Monday, 28 September 2015 at 11:23:25 UTC, Manu wrote: On 28 September 2015 at 09:51, Walter Bright via Digitalmars-d wrote: On 9/27/2015 12:54 AM, Manu via Digitalmars-d wrote: They simply don't recognise its existence. It's a piece of antiquated detritus, only used by strange people who wear woolen shirts pretending to be *nix users while using windows ;) ?? Visual Studio sets all these environment variables, in addition to the usual blizzard set by Microsoft Windows and other Microsoft programs: [...] Huh? We're talking about the environment dialog box right... or so I though? Maybe you're objecting with the suggestion that normal users really do actively use environment variables? If so, your example refers to auto-configured stuff that's completely invisible to average users, as it should be in windows. I've never used the VS command prompt in almost 20 years. Not once. It's only linux ports that require you to mess with the environment in windows. MS would never require that of a user. The alternative view is that MS messed it up so bad that it became nearly impossible to use manually, so they gave up and just wrote complicated automation to deal with it, making 3rd party development harder than it should be. Of course, it doesn't really matter why; it is what it is. That said, I hate environment variables anywhere.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Sunday, 27 September 2015 at 06:34:29 UTC, Walter Bright wrote: On 9/26/2015 10:20 AM, Brad Anderson wrote: Just a little aside tip, Windows search these days is actually really excellent for settings like this (and programs). Windows Key + "env" + Enter is enough to get you to the dialog. Sorry, but the env dialog box is a sad joke, at least on Windows 7. 1. You cannot select any of the text in the dialog. 2. You cannot increase the size of the dialog. 3. Longer values end in "...". 4. You cannot edit so-called "System" environment variables. 5. You can scroll the list up or down, but not sideways! That all conspires to ensure that you CANNOT SEE what the longer values even are! It's pathetic. Back to the command line for me. http://www.rapidee.com/
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Sunday, 27 September 2015 at 06:34:29 UTC, Walter Bright wrote: That all conspires to ensure that you CANNOT SEE what the longer values even are! It's pathetic. Well they finally fixed that, at least. A week ago. http://www.ghacks.net/2015/09/22/microsoft-improves-environment-variables-editor-in-latest-windows-10-build/ ...on the Windows version many people swear they'll never install. -Wyatt
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Monday, 28 September 2015 at 15:08:55 UTC, Wyatt wrote: On Sunday, 27 September 2015 at 06:34:29 UTC, Walter Bright wrote: That all conspires to ensure that you CANNOT SEE what the longer values even are! It's pathetic. Well they finally fixed that, at least. A week ago. http://www.ghacks.net/2015/09/22/microsoft-improves-environment-variables-editor-in-latest-windows-10-build/ ...on the Windows version many people swear they'll never install. Well, I certainly won't be installing any version of Windows newer than 7 for years to come (if ever), but this is great news and _way_ long past due. - Jonathan M Davis
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/28/2015 4:47 AM, John Colvin wrote: The alternative view is that MS messed it up so bad that it became nearly impossible to use manually, so they gave up and just wrote complicated automation to deal with it, making 3rd party development harder than it should be. Of course, it doesn't really matter why; it is what it is. If Microsoft wants to have execrable tools for editting environment variables because environment variables are so yesterday, they should stop using them so extensively.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/28/2015 4:23 AM, Manu via Digitalmars-d wrote: MS would never require that of a user. I find it user unfriendly that I can only use MS command tools from a special command prompt.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/28/2015 8:08 AM, Wyatt wrote: On Sunday, 27 September 2015 at 06:34:29 UTC, Walter Bright wrote: That all conspires to ensure that you CANNOT SEE what the longer values even are! It's pathetic. Well they finally fixed that, at least. A week ago. http://www.ghacks.net/2015/09/22/microsoft-improves-environment-variables-editor-in-latest-windows-10-build/ ...on the Windows version many people swear they'll never install. From the article: "This meant that you had to use copy, delete and paste previously to move variables around." Except that copy/paste does not work in the dialog box (or any Windows dialog box).
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Monday, 28 September 2015 at 19:27:52 UTC, Walter Bright wrote: Except that copy/paste does not work in the dialog box (or any Windows dialog box). Yes it does, you can ctrl+c or right click and get to it from that menu. It works in all Windows edit boxes. You just hit the edit button first to get that single line thing then you can copy/paste out to notepad or whatever.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/28/2015 12:36 PM, Adam D. Ruppe wrote: On Monday, 28 September 2015 at 19:27:52 UTC, Walter Bright wrote: Except that copy/paste does not work in the dialog box (or any Windows dialog box). Yes it does, you can ctrl+c or right click and get to it from that menu. It works in all Windows edit boxes. The dialog box itself is not an edit box, and copy simply does not work. (Just tried it again.) You cannot copy ANY text from it, even the highlighted text. This really blows when you've got a message window with an error message in it, and you cannot copy it to google it. You cannot copy the "About" dialog box text, either, so you have to painfully type in the version/build number when filing a bug report. Unbelievable.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Monday, 28 September 2015 at 11:23:25 UTC, Manu wrote: Maybe you're objecting with the suggestion that normal users really do actively use environment variables? If so, your example refers to auto-configured stuff that's completely invisible to average users, as it should be in windows. I've never used the VS command prompt in almost 20 years. Not once. It's only linux ports that require you to mess with the environment in windows. MS would never require that of a user. I've had to mess with environmental variables quite a bit. I never use VS.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Monday, 28 September 2015 at 19:44:11 UTC, Walter Bright wrote: On 9/28/2015 12:36 PM, Adam D. Ruppe wrote: On Monday, 28 September 2015 at 19:27:52 UTC, Walter Bright wrote: Except that copy/paste does not work in the dialog box (or any Windows dialog box). Yes it does, you can ctrl+c or right click and get to it from that menu. It works in all Windows edit boxes. The dialog box itself is not an edit box, and copy simply does not work. (Just tried it again.) You cannot copy ANY text from it, even the highlighted text. This really blows when you've got a message window with an error message in it, and you cannot copy it to google it. You cannot copy the "About" dialog box text, either, so you have to painfully type in the version/build number when filing a bug report. Unbelievable. Dear Walter, Pressing Ctrl-C in any *standard* dialog will copy the text to clipboard since Windows 2000, even captions and buttons.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Monday, 28 September 2015 at 21:41:27 UTC, rumbu wrote: On Monday, 28 September 2015 at 19:44:11 UTC, Walter Bright wrote: On 9/28/2015 12:36 PM, Adam D. Ruppe wrote: On Monday, 28 September 2015 at 19:27:52 UTC, Walter Bright wrote: Except that copy/paste does not work in the dialog box (or any Windows dialog box). Yes it does, you can ctrl+c or right click and get to it from that menu. It works in all Windows edit boxes. The dialog box itself is not an edit box, and copy simply does not work. (Just tried it again.) You cannot copy ANY text from it, even the highlighted text. This really blows when you've got a message window with an error message in it, and you cannot copy it to google it. You cannot copy the "About" dialog box text, either, so you have to painfully type in the version/build number when filing a bug report. Unbelievable. Dear Walter, Pressing Ctrl-C in any *standard* dialog will copy the text to clipboard since Windows 2000, even captions and buttons. And before telling that don't work, this a remote desktop connection to a non existent computer error obtained using Ctrl-C: [Window Title] Remote Desktop Connection [Content] Remote Desktop can't find the computer "abcd". This might mean that "abcd" does not belong to the specified network. Verify the computer name and domain that you are trying to connect to. [OK] [Help]
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/28/2015 2:41 PM, rumbu wrote: Pressing Ctrl-C in any *standard* dialog will copy the text to clipboard since Windows 2000, even captions and buttons. Nope. Doesn't work in the Environment Variables dialog box. Doesn't work in the Thunderbird about box. Doesn't work in the Notepad about box. Doesn't work in the IE about box. Or any of the IE dialog boxes I tried, like Internet Options. I haven't found ANY where it works.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Monday, 28 September 2015 at 23:44:55 UTC, Walter Bright wrote: On 9/28/2015 2:41 PM, rumbu wrote: Pressing Ctrl-C in any *standard* dialog will copy the text to clipboard since Windows 2000, even captions and buttons. Nope. Doesn't work in the Environment Variables dialog box. Doesn't work in the Thunderbird about box. Doesn't work in the Notepad about box. Doesn't work in the IE about box. Or any of the IE dialog boxes I tried, like Internet Options. I haven't found ANY where it works. Hmmm. I'm don't know what you're doing differently from the rest of us. Certainly, the text in about boxes isn't usually selectable, but aren't we specifically talking about the dialog for editing environment variables here? If I open the environment variable dialog, select Path, and click on the edit button, I get a dialog that pops up that has the "Variable name:" and "Variable value:" fields. The text "Variable name:" and "Variable value:" is unselectable and not copyable (so maybe that's what you're talking about?), but the text in the edit boxes next to them where you edit their values _can_ be selected and copied. If I click on the text in the box to the right of "Variable value:", hit ctrl-a to select all of the text, and then hit ctrl-c, I get this on my clipboard: C:\ProgramData\Oracle\Java\javapath;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\AMD\ATI.ACE\Core-Static;C:\Program Files (x86)\Shoreline Communications\ShoreWare Client\;C:\Program Files (x86)\Shoreline Communications\ShoreWare Client\win64;C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;%TFSPowerToolDir%;%BPADir%;C:\Program Files (x86)\Vim\vim74;C:\Program Files\Microsoft\Web Platform Installer\;C:\D\dmd2\windows\bin And I can now edit that text and copy it back into the edit field for the Path variable, which is stupid to have to do but is a lot saner than editing the text in the edit box directly. - Jonathan M Davis
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/28/2015 6:42 PM, Jonathan M Davis wrote: On Monday, 28 September 2015 at 23:44:55 UTC, Walter Bright wrote: On 9/28/2015 2:41 PM, rumbu wrote: Pressing Ctrl-C in any *standard* dialog will copy the text to clipboard since Windows 2000, even captions and buttons. Nope. Doesn't work in the Environment Variables dialog box. Doesn't work in the Thunderbird about box. Doesn't work in the Notepad about box. Doesn't work in the IE about box. Or any of the IE dialog boxes I tried, like Internet Options. I haven't found ANY where it works. Hmmm. I'm don't know what you're doing differently from the rest of us. Certainly, the text in about boxes isn't usually selectable, but aren't we specifically talking about the dialog for editing environment variables here? If I open the environment variable dialog, select Path, and click on the edit button, Try selecting any text in the dialog box before opening another one with the edit button. Or try any of the ones I mentioned. > And I can now edit that text and copy it back into the edit field for the Path variable, which is stupid to have to do but is a lot saner than editing the text in the edit box directly. Surely a dialog box stinks if you have to paste its contents into an editor to edit it.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Tuesday, 29 September 2015 at 03:33:20 UTC, Walter Bright wrote: On 9/28/2015 6:42 PM, Jonathan M Davis wrote: On Monday, 28 September 2015 at 23:44:55 UTC, Walter Bright wrote: On 9/28/2015 2:41 PM, rumbu wrote: Pressing Ctrl-C in any *standard* dialog will copy the text to clipboard since Windows 2000, even captions and buttons. Nope. Doesn't work in the Environment Variables dialog box. Doesn't work in the Thunderbird about box. Doesn't work in the Notepad about box. Doesn't work in the IE about box. Or any of the IE dialog boxes I tried, like Internet Options. I haven't found ANY where it works. Hmmm. I'm don't know what you're doing differently from the rest of us. Certainly, the text in about boxes isn't usually selectable, but aren't we specifically talking about the dialog for editing environment variables here? If I open the environment variable dialog, select Path, and click on the edit button, Try selecting any text in the dialog box before opening another one with the edit button. Or try any of the ones I mentioned. Well, I would have thought that it was clearly designed with the idea that you'd click on the edit button to edit it. And you can copy and paste the data from the edit dialog. So, not being able to edit the fields in the first dialog really isn't a big deal IMHO, though what they give you with the edit dialog really isn't any better than simply being able to edit it in the initial dialog. So, in that sense, maybe they should have just made it editable in the first dialog rather than having to open one specifically to edit it, though it would be far better to actually make the edit dialog sane rather than just a simple text box. Fortunately though, it sounds like the edit dialog is finally becoming sane with Windows 10. > And I can now edit that text and copy it back into the edit field for the Path variable, which is stupid to have to do but is a lot saner than editing the text in the edit box directly. Surely a dialog box stinks if you have to paste its contents into an editor to edit it. Well, of course, it sucks. Having the PATH be edited via a single text field isn't even vaguely user friendly. Copy-pasting to edit it just a way to make it slightly more sane. What it really needs is to be revamped in a manner similar to what they've apparently finally done with Windows 10. - Jonathan M Davis
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/28/2015 11:16 PM, Jonathan M Davis wrote: Well, I would have thought that it was clearly designed with the idea that you'd click on the edit button to edit it. And you can copy and paste the data from the edit dialog. I should be able to copy any text on the screen.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Monday, 28 September 2015 at 23:44:55 UTC, Walter Bright wrote: On 9/28/2015 2:41 PM, rumbu wrote: Pressing Ctrl-C in any *standard* dialog will copy the text to clipboard since Windows 2000, even captions and buttons. Nope. Doesn't work in the Environment Variables dialog box. Doesn't work in the Thunderbird about box. Doesn't work in the Notepad about box. Doesn't work in the IE about box. Or any of the IE dialog boxes I tried, like Internet Options. I haven't found ANY where it works. That applies to error messages that use standard windows message box: This really blows when you've got a message window with an error message in it, and you cannot copy it to google it.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Tuesday, 29 September 2015 at 07:29:23 UTC, Walter Bright wrote: On 9/28/2015 11:16 PM, Jonathan M Davis wrote: Well, I would have thought that it was clearly designed with the idea that you'd click on the edit button to edit it. And you can copy and paste the data from the edit dialog. I should be able to copy any text on the screen. Well, I don't know of any operating system where that's possible. For instance, clicking on the title bar and dragging the mouse is going to result in the window being dragged in every desktop environment that I know of, not select the text on it, and it would never work for the text on a button to be selectable, since any attempt to select it would press the button. Maybe more of the text in GUIs should be copyable than is, but that's pretty clearly not generally a goal of GUI designers or of how GUI toolkits are designed. There have certainly been times where I've wanted to copy text that was not selectable for some reason (or selectable but not copyable), but it sounds like you have a much higher expectation of text selectability than I do. - Jonathan M Davis
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Monday, 28 September 2015 at 19:44:11 UTC, Walter Bright wrote: This really blows when you've got a message window with an error message in it, and you cannot copy it to google it. You cannot copy the "About" dialog box text, either, so you have to painfully type in the version/build number when filing a bug report. AFAIK, bugzilla supports simple links that create a bug report with prefilled information like program version, so a better way is to provide such link in the program interface similar to bugreporting scripts in linux that gather all relevant system information as an attachment.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 09/28/2015 03:44 PM, Walter Bright wrote: The dialog box itself is not an edit box, and copy simply does not work. (Just tried it again.) You cannot copy ANY text from it, even the highlighted text. This really blows when you've got a message window with an error message in it, and you cannot copy it to google it. You cannot copy the "About" dialog box text, either, so you have to painfully type in the version/build number when filing a bug report. Unbelievable. That's one of the many reasons I absolutely despise the modern crop of mobile OSes. (As opposed to PalmOS which worked REALLY damn well, at least aside from the lack of WiFi which wouldn't have been realistic in those days anyway. VERY productive and speedy interface. Puts the modern smartphones completely to shame.)
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Monday, 28 September 2015 at 21:41:27 UTC, rumbu wrote: Dear Walter, Pressing Ctrl-C in any *standard* dialog will copy the text to clipboard since Windows 2000, even captions and buttons. No, standard label controls still don't let you select and copy the text. And that sucks.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On 9/29/2015 1:58 AM, Jonathan M Davis wrote: There have certainly been times where I've wanted to copy text that was not selectable for some reason (or selectable but not copyable), but it sounds like you have a much higher expectation of text selectability than I do. Cases that frustrate me: 1. In filing a bug report, I need to input the version number. For Internet Explorer, I bring up the "About Internet Explorer" dialog box. The version is (I kid you not) a 55 character string of random digits and letters. I want to cut&paste this. Not possible. 2. I get a dialog box popping up with an error message in it. I want to google the error message. Have to retype it. 3. Thunderbird Mail lets me import/export the address book. But not account settings. So I want to select and copy the account settings dialog box. Nope. Really, what's the case for not supporting this? Am I really a unique snowflake?
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Tue, Sep 29, 2015 at 04:50:37PM -0700, Walter Bright via Digitalmars-d wrote: > On 9/29/2015 1:58 AM, Jonathan M Davis wrote: > >There have certainly been times where I've wanted to copy text that > >was not selectable for some reason (or selectable but not copyable), > >but it sounds like you have a much higher expectation of text > >selectability than I do. > > Cases that frustrate me: > > 1. In filing a bug report, I need to input the version number. For > Internet Explorer, I bring up the "About Internet Explorer" dialog > box. The version is (I kid you not) a 55 character string of random > digits and letters. I want to cut&paste this. Not possible. > > 2. I get a dialog box popping up with an error message in it. I want > to google the error message. Have to retype it. > > 3. Thunderbird Mail lets me import/export the address book. But not > account settings. So I want to select and copy the account settings > dialog box. Nope. > > Really, what's the case for not supporting this? Am I really a unique > snowflake? Nope, you're just too smart to use a GUI. ;-) Issues like these were part of what convinced me that the so-called desktop metaphor was bunk and that the current infatuation with GUIs is a case of emperor's clothes, and drove me to embrace the *nix shell. Editing configuration files in a text editor is far more productive than trying to fight with a GUI designed for dummies, especially when you need to do something that the GUI designers did not anticipate. A particular annoyance recently that almost drove me to tear out my hair was also a case of non-resizeable dialogs in Windows (I have the misfortune of needing to use my wife's Windows laptop from time to time). Obviously, that dialog was designed with the (shaky!) assumption that (1) users do not change the default font size, which may cause the chosen design size of the dialog to be far too small to display all pertinent information, (2) filenames may be far longer than anticipated, thereby not fitting into the (IMO far too small) dialog size, (3) the user is too dumb to know how to use a window resizing function in a dialog box (or more likely, the programmer was too lazy to implement such a feature), and (4) it shouldn't matter if part of the information is cut off from view (with no option of getting at it even if you wanted to!) because most users don't care about that level of information anyway, so one could get away with just a perfunctory display of partial information and let the power users suffer for choosing to use something not designed for them in the first place. Nevermind the fact that supposedly "irrelevant" information is highly pertinent when you're dealing with filenames that differ in their last few characters (e.g., "veryLongFilename-01" vs. "veryLongFilename-02", when you're trying to examine a series of files in sequence). But nooo, that only means the user is too smart to be part of our target audience, so too bad for him. Sigh. T -- Let's eat some disquits while we format the biskettes.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Tuesday, 29 September 2015 at 23:50:34 UTC, Walter Bright wrote: On 9/29/2015 1:58 AM, Jonathan M Davis wrote: There have certainly been times where I've wanted to copy text that was not selectable for some reason (or selectable but not copyable), but it sounds like you have a much higher expectation of text selectability than I do. Cases that frustrate me: 1. In filing a bug report, I need to input the version number. For Internet Explorer, I bring up the "About Internet Explorer" dialog box. The version is (I kid you not) a 55 character string of random digits and letters. I want to cut&paste this. Not possible. 2. I get a dialog box popping up with an error message in it. I want to google the error message. Have to retype it. 3. Thunderbird Mail lets me import/export the address book. But not account settings. So I want to select and copy the account settings dialog box. Nope. Really, what's the case for not supporting this? Am I really a unique snowflake? No, you're alone, though it's not something that I think about often. I think that most of us run into this sort of problem from time to time (e.g. for some reason, the VPN client that I use for work won't let you copy-paste the IP address that you're connected to, so you have to read it and type it out by hand every time that you need to give it to someone, which is just silly). But there are aspects of GUIs where I don't think that it's really reasonable to expect to be able to copy the text, because it would interfere with how the GUI works (e.g. the text on a button). So, I _expect_ there to be times when I can't copy a piece text from a GUI. However, that being said, I don't think that there's any question that more text should be selectable and copyable than is. It looks like KDE made is that you can select the text in their about boxes. I have no idea why Microsoft didn't. And it's just plain embarrassing that Microsoft wouldn't let you copy error messages from error dialogs. But I think that it mostly comes down to the folks who put GUIs together not thinking about this sort of thing. It really isn't related to the primary functionality of an application, so it's easy to forget. And in many cases, I expect that it comes down to exactly what kind of GUI widget was used to display the text, and if the toolkit in question wasn't designed with this in mind, then everyone using it is going to end up with unselectable and uncopyable text in their GUIs - which just goes to show, I suppose, that if the GUI toolkit folks get it right, then a lot of programs will, and I guess that Win32 or MFC or whatever C# thing Microsoft and many other Windows shops use for many of their GUIs don't do it right. - Jonathan M Davis
