www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Pathing in the D ecosystem is generally broken (at least on windows)

reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Sep 24 2015
next sibling parent Kagamin <spam here.lot> writes:
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.
Sep 25 2015
prev sibling next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
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.
Sep 25 2015
next sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
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.
Sep 25 2015
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
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.
Sep 25 2015
next sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
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.
Sep 25 2015
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 25 September 2015 at 22:17, Kagamin via Digitalmars-d
<digitalmars-d puremagic.com> 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.
Sep 25 2015
parent reply anon <anon anon.ne> writes:
On Saturday, 26 September 2015 at 01:37:57 UTC, Manu wrote:
 On 25 September 2015 at 22:17, Kagamin via Digitalmars-d 
 <digitalmars-d puremagic.com> 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 !
Sep 25 2015
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 September 2015 at 14:24, anon via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Saturday, 26 September 2015 at 01:37:57 UTC, Manu wrote:
 On 25 September 2015 at 22:17, Kagamin via Digitalmars-d
 <digitalmars-d puremagic.com> 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.
Sep 25 2015
prev sibling next sibling parent Dicebot <public dicebot.lv> writes:
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.
Sep 25 2015
prev sibling parent Brad Anderson <eco gnuk.net> writes:
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).
Sep 25 2015
prev sibling next sibling parent ponce <contact gam3sfrommars.fr> writes:
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.
Sep 25 2015
prev sibling next sibling parent reply ponce <contact gam3sfrommars.fr> writes:
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.
Sep 25 2015
parent reply Mike Parker <aldacron gmail.com> writes:
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.
Sep 25 2015
parent reply Kagamin <spam here.lot> writes:
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.
Sep 25 2015
parent reply Brad Anderson <eco gnuk.net> writes:
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).
Sep 25 2015
parent Casper =?UTF-8?B?RsOmcmdlbWFuZA==?= <shorttail hotmail.com> writes:
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
Sep 25 2015
prev sibling next sibling parent reply Dicebot <public dicebot.lv> writes:
Hm, so is the correct approach on Windows to provide separate 
shell for each application that has console utilities? X_x
Sep 25 2015
next sibling parent reply Kagamin <spam here.lot> writes:
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.
Sep 25 2015
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
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.
Sep 25 2015
next sibling parent reply Kagamin <spam here.lot> writes:
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.
Sep 25 2015
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Sep 25 2015
next sibling parent reply Kagamin <spam here.lot> writes:
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.
Sep 25 2015
parent reply Dicebot <public dicebot.lv> writes:
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)
Sep 25 2015
next sibling parent reply Kagamin <spam here.lot> writes:
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.
Sep 25 2015
parent reply Dicebot <public dicebot.lv> writes:
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.
Sep 25 2015
parent Kagamin <spam here.lot> writes:
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.
Sep 25 2015
prev sibling parent Kagamin <spam here.lot> writes:
BTW, it's not very difficult to invoke the linker directly.
Sep 25 2015
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 September 2015 at 02:30, Jonathan M Davis via Digitalmars-d
<digitalmars-d puremagic.com> 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.
Sep 25 2015
parent reply Jacob Carlborg <doob me.com> writes:
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
Sep 26 2015
parent reply extrawurst <stephan extrawurst.org> writes:
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
Sep 26 2015
parent reply Jacob Carlborg <doob me.com> writes:
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
Sep 27 2015
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 27 September 2015 at 19:26, Jacob Carlborg via Digitalmars-d
<digitalmars-d puremagic.com> 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!
Sep 27 2015
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 25 Sep 2015 16:30:03 +0000
schrieb Jonathan M Davis <jmdavisProg gmx.com>:

 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.
Sep 26 2015
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 25 September 2015 at 15:43:46 UTC, John Colvin wrote:
 On Friday, 25 September 2015 at 15:40:54 UTC, Kagamin wrote:
 On Friday, 25 September 2015 at 12:50:55 UTC, John Colvin 
 wrote:
 The complexity of the tradeoff is exactly why experienced 
 windows developers are necessary here. For example: any 
 tradeoffs I designed would likely be very far from 
 pareto-optimal on windows, let alone be a good solution 
 overall.
No, a tradeoff is a tradeoff, one tradeoff is not better than another
That's what pareto-optimal means.
<Putting on my economist hat> Pareto optimal means you can't make anybody better off without making somebody worse off (you used it properly above...). It's very easy to show that it's possible to have one trade-off be better than another. For instance, suppose I am indifferent between purchasing 1 TV or 1 computer. This is trade-off 1. Alternately, I am also indifferent between buying 2 TVs or 2 computers or 1 TV and 1 computer. This is trade-off 2. However, I prefer the second set of trade-offs to the first set of trade-offs because I prefer more stuff. I'm probably over-analyzing this... An alternative to Pareto is Kalder-Hicks efficiency. A Kalder-Hicks improvement means that the people who are better off from some change are sufficiently better off from that change that they could compensate the people who are worse off from the change if they wanted to. Maybe that is a better framework for thinking about things.
Sep 25 2015
prev sibling parent reply Dicebot <public dicebot.lv> writes:
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`.
Sep 25 2015
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Sep 25 2015
prev sibling next sibling parent Kagamin <spam here.lot> writes:
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 :)
Sep 25 2015
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 September 2015 at 02:06, Dicebot via Digitalmars-d
<digitalmars-d puremagic.com> 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.
Sep 25 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 :-(
Sep 25 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 25 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 September 2015 at 13:29, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> 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.
Sep 25 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 25 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 September 2015 at 15:17, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> 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.
Sep 26 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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!
Sep 26 2015
next sibling parent reply Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Sep 26 2015
next sibling parent reply Laeeth Isharc <spamnolaeeth nospamlaeeth.com> writes:
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.
Sep 26 2015
parent reply Joakim <dlang joakim.fea.st> writes:
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.digitalmars-d puremagic.com http://forum.dlang.org/post/dmfr07$2u3u$1 digitaldaemon.com http://forum.dlang.org/post/euuvum$171f$1 digitalmars.com
Sep 26 2015
parent reply Laeeth Isharc <spamnolaeeth nospamlaeeth.com> writes:
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.digitalmars-d 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.
Sep 26 2015
parent reply Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Sep 26 2015
next sibling parent Laeeth Isharc <spamnolaeeth nospamlaeeth.com> writes:
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 that's not a license to allow others to redistribute, so maybe that causes problems with LLVM.
 every
 other `free-but-entangled-with-non-free` part of DMD has the 
 same problem.
Enough controversy for me for a while, so let's leave it at that. I presume you're an LLVM contributor, and so I can see that you may have special constraints. Laeeth.
Sep 26 2015
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
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.
Sep 26 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 26 2015
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Sep 26 2015
parent reply David Nadlinger <code klickverbot.at> writes:
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
Sep 26 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
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!
Sep 26 2015
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2015 9:06 AM, Dicebot wrote:
 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.
We're in the process of switching the Win32 dmd toolchain to use "optlink.exe" rather than "link.exe". Should have done that a long time ago.
Sep 29 2015
prev sibling parent Kagamin <spam here.lot> writes:
FWIW looks like there's another conflict with lib.exe: 
https://issues.dlang.org/show_bug.cgi?id=14558
Nov 05 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 25 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 September 2015 at 13:20, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> 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.
Sep 25 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 25 2015
next sibling parent reply schweik <schweik nowhere.de> writes:
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.
Sep 25 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 September 2015 at 16:35, schweik via Digitalmars-d
<digitalmars-d puremagic.com> 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 support CV8 debuginfo, or Emscripten, but I'll keep trying, maybe get there one day... :/ </rant> ... sorry!
Sep 26 2015
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Sep 26 2015
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Sep 26 2015
prev sibling next sibling parent Joakim <dlang joakim.fea.st> writes:
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.
Sep 26 2015
prev sibling parent schweik <schweik nowhere.de> writes:
On Saturday, 26 September 2015 at 09:51:19 UTC, Manu wrote:
 On 26 September 2015 at 16:35, schweik via Digitalmars-d 
 <digitalmars-d puremagic.com> 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.
Sep 26 2015
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 September 2015 at 15:35, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> 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).
Sep 26 2015
prev sibling parent reply Brad Anderson <eco gnuk.net> writes:
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.
Sep 26 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 26 2015
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Sep 26 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 27 September 2015 at 16:52, Jonathan M Davis via Digitalmars-d
<digitalmars-d puremagic.com> 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 ;)
Sep 27 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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\
Sep 27 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 28 September 2015 at 09:51, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> 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.
Sep 28 2015
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Monday, 28 September 2015 at 11:23:25 UTC, Manu wrote:
 On 28 September 2015 at 09:51, Walter Bright via Digitalmars-d 
 <digitalmars-d puremagic.com> 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.
Sep 28 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 28 2015
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 28 2015
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
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.
Sep 28 2015
prev sibling next sibling parent Tourist <gravatar gravatar.com> writes:
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/
Sep 28 2015
prev sibling parent reply Wyatt <wyatt.epp gmail.com> writes:
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
Sep 28 2015
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Sep 28 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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).
Sep 28 2015
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Sep 28 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 28 2015
next sibling parent reply rumbu <rumbu rumbu.ro> writes:
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.
Sep 28 2015
next sibling parent rumbu <rumbu rumbu.ro> writes:
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]
Sep 28 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 28 2015
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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\WindowsPowerSh ll\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
Sep 28 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 28 2015
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Sep 28 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 29 2015
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Sep 29 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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?
Sep 29 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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.
Sep 29 2015
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 30 September 2015 at 00:20:46 UTC, H. S. Teoh wrote:
 On Tue, Sep 29, 2015 at 04:50:37PM -0700, Walter Bright via 
 Digitalmars-d wrote:
 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.
GUIs work quite well for certain types of applications - especially those that are very visual (e.g. Photoshop). And in general, if they're done correctly, they allow you to do a certain set of operations efficiently and easily, but by their very nature, they don't tend to be very flexible, and when you do try and make them flexible, they tend to get very complicated, very fast. Contrast that with Unix utilities, which are usually designed to do one job and do it well and then interoperate with other such utilities cleanly. Because each one is simple, they work well, and because they're composable, you have a _lot_ more flexibility than you get with a GUI. So, in general, the unix philosophy just ends up working better. But it _does_ require a certain kind of thinking from the user that tends to go well with programmers but not so well with the average joe, and even with that in mind, there _are_ applications that work better as GUIs. But it's that simplicity and composability that gives us a lot of the power that we have with ranges, and I think that you can see some comparisons between a range-based approach and what you'd typically get in many other languages (particularly when OO is involved), where you often end up with objects that have everything and the kitchen sink in them, which can be quite useful and in some cases, easier to use, but ultimately it's a lot less flexible and harder to maintain. - Jonathan M Davis
Sep 29 2015
next sibling parent Laeeth Isharc <laeethnospam nospamlaeeth.com> writes:
On Wednesday, 30 September 2015 at 01:59:38 UTC, Jonathan M Davis 
wrote:
 On Wednesday, 30 September 2015 at 00:20:46 UTC, H. S. Teoh 
 wrote:
 On Tue, Sep 29, 2015 at 04:50:37PM -0700, Walter Bright via 
 Digitalmars-d wrote:
 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.
GUIs work quite well for certain types of applications - especially those that are very visual (e.g. Photoshop). And in general, if they're done correctly, they allow you to do a certain set of operations efficiently and easily, but by their very nature, they don't tend to be very flexible, and when you do try and make them flexible, they tend to get very complicated, very fast. Contrast that with Unix utilities, which are usually designed to do one job and do it well and then interoperate with other such utilities cleanly. Because each one is simple, they work well, and because they're composable, you have a _lot_ more flexibility than you get with a GUI. So, in general, the unix philosophy just ends up working better. But it _does_ require a certain kind of thinking from the user that tends to go well with programmers but not so well with the average joe, and even with that in mind, there _are_ applications that work better as GUIs.
Excellent unfolding of this point, and one I have been pondering for my own use case. I would like to be able to explore data interactively using various building blocks written in D that I can strap together quickly. User interfaces matter so much for things you do everyday, yet often people are more concerned with making it shiny for the marketing guys than productive for serious users - especially so for relative monopolies. It's interesting to see how different applications tackle this problem. It doesn't necessarily need to be either GUI or command line. For example, the Bloomberg terminal is kind of a combination (more old-school GUI than not, and the GUI bit is the one I like least). The ipython/Jupyter notebook is another kind - that's great for writing intermediate size chunks of code but not so much for use as a shell. So another possibility is the qtconsole style. (Maybe R and Julia, but I am less familiar with those). I think in both Jupyter and qtconsole you can have graphical widgets (certainly in Jupyter). Adam Ruppe's terminal is quite an interesting approach. as you can display images inline within the terminal window, and not hard to make them interactive. Possibly a shell with graphics and some kind of light scripting language like Lua can be the best of both worlds, in particular in relation to the composability aspect. In Bloomberg if I want to see which bonds are deliverable for the front month gilt future, I can type "G A[F9]DLV[ENTER]" and see an editable analysis window pop up - not quite a commandline, but shortcuts on steroids. It's easy to replicate this kind of shortcut in a terminal (including prompts/helptext etc) whilst still having the ability to do more powerful things using the commandline without context switching. for example findticker --macro --confidence/consumer GBP | less (not something that will go quickly in Bloomberg because GUI). or findticker -- macro --confidence/consumer OECD | chart -s 2009 -f monthly (find all OECD consumer confidence numbers and plot them since 2009) Laeeth.
Sep 29 2015
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 30, 2015 at 01:59:36AM +0000, Jonathan M Davis via Digitalmars-d
wrote:
 On Wednesday, 30 September 2015 at 00:20:46 UTC, H. S. Teoh wrote:
[...]
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.
GUIs work quite well for certain types of applications - especially those that are very visual (e.g. Photoshop). And in general, if they're done correctly, they allow you to do a certain set of operations efficiently and easily, but by their very nature, they don't tend to be very flexible, and when you do try and make them flexible, they tend to get very complicated, very fast.
Oh, I agree that certain tasks are better suited for GUIs. For example, highly visual tasks like freehand drawing, photo-editing (Photoshop), etc., are clearly better suited to a graphical interface. Many things aren't, though, in spite of people trying to shoehorn them into GUIs because GUIs are k00l and therefore we must do GUI or we're not in the in-crowd.
 Contrast that with Unix utilities, which are usually designed to do
 one job and do it well and then interoperate with other such utilities
 cleanly.  Because each one is simple, they work well, and because
 they're composable, you have a _lot_ more flexibility than you get
 with a GUI. So, in general, the unix philosophy just ends up working
 better. But it _does_ require a certain kind of thinking from the user
 that tends to go well with programmers but not so well with the
 average joe, and even with that in mind, there _are_ applications that
 work better as GUIs.
I know the commandline scares away your average joe. That's the kind of audience GUIs are catered to, which is understandable. What gets annoying is when you're *forced* to use GUI even if you're not the average joe. Many tasks in Windows simply cannot be done without clicking through the GUI. You have no choice in the matter. Where it get ugly is when the GUIs in question have issues, like non-resizeability or non-copyability where there's no *technical* reason why it cannot be done. That's when I start wishing it was Linux where I can just fire up a text editor and edit system config files directly instead of getting an aneurysm from clicking the rodent trying to coax it to do what I want.
 But it's that simplicity and composability that gives us a lot of the
 power that we have with ranges, and I think that you can see some
 comparisons between a range-based approach and what you'd typically
 get in many other languages (particularly when OO is involved), where
 you often end up with objects that have everything and the kitchen
 sink in them, which can be quite useful and in some cases, easier to
 use, but ultimately it's a lot less flexible and harder to maintain.
[...] The infamous god-object? I thought that was an antipattern... As is the static singleton class, which is so widespread in Java because their fixation on OO doctrine prohibits free functions as a matter of orthodoxy, even though many things are really better off as free functions than class members. To me, such shenanigans are a code smell symptomic of an underlying design / conceptual flaw, just as the sometimes ridiculous shenanigans you have to go through in order to make something work as a GUI when clearly a different kind of interface would be much better suited. But such suggestions are usually shot down by various standard fallacies ("non-GUI == not user-friendly", "nobody uses CLI anymore", "GUI == k00l, CLI == not k00l", etc.) and never seriously considered, even though they really should be. T -- It only takes one twig to burn down a forest.
Sep 29 2015
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 30 September 2015 at 04:48:35 UTC, H. S. Teoh wrote:
 On Wed, Sep 30, 2015 at 01:59:36AM +0000, Jonathan M Davis via 
 Digitalmars-d wrote:
 I know the commandline scares away your average joe. That's the 
 kind of audience GUIs are catered to, which is understandable. 
 What gets annoying is when you're *forced* to use GUI even if 
 you're not the average joe. Many tasks in Windows simply cannot 
 be done without clicking through the GUI. You have no choice in 
 the matter. Where it get ugly is when the GUIs in question have 
 issues, like non-resizeability or non-copyability where there's 
 no *technical* reason why it cannot be done. That's when I 
 start wishing it was Linux where I can just fire up a text 
 editor and edit system config files directly instead of getting 
 an aneurysm from clicking the rodent trying to coax it to do 
 what I want.
Yeah. A big problem with mobile platforms, Windows, and Mac OS X is that they all tend to target the average joe and don't necessarily give the power users good tools (I suspect that Mac OS X does the best out of those given its BSD underpinnings, but I haven't used it, so I don't know). Linux and the BSDs do a _far_ better job - probably because they're pretty much written by geeks for geeks. They're not trying to dumb everything down. I hate dealing with mobile precisely because they're trying to hide the fact that it's a computer and are trying to dumb the whole thing down for the average joe. Windows isn't as bad, but even when it does a fairly good job, it's still catering to folks who are scared of the command line. And some of the changes that they've made over time have the same problems as the mobile OSes where they're basically trying to hide a lot of stuff from the user - especially stuff related to the filesystem.
 But it's that simplicity and composability that gives us a lot 
 of the power that we have with ranges, and I think that you 
 can see some comparisons between a range-based approach and 
 what you'd typically get in many other languages (particularly 
 when OO is involved), where you often end up with objects that 
 have everything and the kitchen sink in them, which can be 
 quite useful and in some cases, easier to use, but ultimately 
 it's a lot less flexible and harder to maintain.
[...] The infamous god-object? I thought that was an antipattern...
It doesn't usually go _that_ far, but when using OO, it's still pretty common to put everything on the class, and very little is generic. So, if functionality gets added, it gets added to the class that the programmer wants to use it with at the time. It actually tends to make it easier to find functionality, because it's grouped with what it's used with and documented with it, but it really isn't reusable. So, even if a class isn't so complicated that it's a god-object, it can still have way more functionality on it than necessarily makes sense, especially if you start thinking about generic programming and being able to reuse functionality. Another example would be frameworks vs libraries / components. With a framework, the programmer that wrote it provides most of the functionality, and you override and/or fill-in pieces of it for your particular application. It saves you a lot of time and effort, because you don't have to code it all up yourself, and often, you don't even have to understand that much about how any of it works, because it's doing so much for you. However, a framework generally isn't very flexible (or if it is, it gets _very_ complicated, very quickly), and its code isn't particularly reusable, because it's only usable within the framework. So, from the perspective of a beginner or someone trying to get something done that doesn't require much flexibility, a framework might be a great solution. But as soon as you need to do anything that the framework folks didn't think of or which doesn't fit in well with how the framework is designed, you're pretty much screwed and forced to ditch the framework entirely. Contrast that with a library built entirely of reusable components that can be used to build functionality similar to that of the framework. It's probably going to be harder to use for some cases, because it's generally not doing as much for you out-of-the-box, but you can build what the framework does using the components it gives you, and you can build completely different stuff using those same components. You get a lot more flexibility and power out of it - but less hand-holding. Good GUIs solve the common case well but don't generally do well for uncommon cases, and unlike command-line tools, they can't be used to build something else that isn't as common.
 But such suggestions are usually shot down by various standard 
 fallacies ("non-GUI == not user-friendly", "nobody uses CLI 
 anymore", "GUI == k00l, CLI == not k00l", etc.) and never 
 seriously considered, even though they really should be.
To be fair, for most people, CLI _isn't_ user-friendly - e.g. I sure wouldn't want to require that my mother use the command line. She has enough trouble with GUIs. As you mentioned, the problem is when everything is targeting the average joe and power users aren't given good tools. Having stuff that caters to the average joe is fine. It's when that's all they're doing that we have a problem. - Jonathan M Davis
Sep 30 2015
prev sibling parent Kagamin <spam here.lot> writes:
On Wednesday, 30 September 2015 at 04:48:35 UTC, H. S. Teoh wrote:
 I know the commandline scares away your average joe. That's the 
 kind of audience GUIs are catered to, which is understandable. 
 What gets annoying is when you're *forced* to use GUI even if 
 you're not the average joe. Many tasks in Windows simply cannot 
 be done without clicking through the GUI. You have no choice in 
 the matter. Where it get ugly is when the GUIs in question have 
 issues, like non-resizeability or non-copyability where there's 
 no *technical* reason why it cannot be done. That's when I 
 start wishing it was Linux where I can just fire up a text 
 editor and edit system config files directly instead of getting 
 an aneurysm from clicking the rodent trying to coax it to do 
 what I want.
Well, any interface may or may not provide desired features. It being config files, CLI or API, every feature still must be implemented, and if it's not the user is out of luck.
Sep 30 2015
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Sep 29 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/29/2015 6:51 PM, Jonathan M Davis wrote:
 On Tuesday, 29 September 2015 at 23:50:34 UTC, Walter Bright wrote:
 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.
I should be able to copy the button text by starting the stroke from outside the button and crossing over it.
 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.
Microsoft should: 1. fix it so it is the default behavior. 2. list it in their guidelines for how dialog boxes should work.
Sep 29 2015
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 09/29/2015 10:27 PM, Walter Bright wrote:
 Microsoft should:
 1. fix it so it is the default behavior.
 2. list it in their guidelines for how dialog boxes should work.
There's a LOT of things Microsoft really should do. Even having been a Win guy for a long, long time, I've long since given up on MS ever doing nearly any of the things they really should. (Not to specifically single MS out, lot of other companies/groups are much the same.)
Oct 02 2015
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 30-Sep-2015 02:50, 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?
When that happens to me I use Abbyy FineReader to OCR the screenshot, there is even a special screenshot reader app. Sometimes it's a lifesaver. -- Dmitry Olshansky
Sep 29 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/29/2015 11:03 PM, Dmitry Olshansky wrote:
 When that happens to me I use Abbyy FineReader to OCR the screenshot, there is
 even a special screenshot reader app. Sometimes it's a lifesaver.
I use a flamethrower to light cigarettes, too!
Sep 30 2015
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 09/30/2015 06:34 AM, Walter Bright wrote:
 On 9/29/2015 11:03 PM, Dmitry Olshansky wrote:
 When that happens to me I use Abbyy FineReader to OCR the screenshot,
 there is
 even a special screenshot reader app. Sometimes it's a lifesaver.
I use a flamethrower to light cigarettes, too!
Best comeback ever. :)
Oct 02 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-09-30 01:50, Walter Bright wrote:

 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.
You clearly are not using the right operating system ;). On OS X I can copy text from all native dialogs.
 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.
Can't you copy the editable text fields? Or do you want to copy the labels as well? Can't you copy the whole profile directory?
 Really, what's the case for not supporting this? Am I really a unique
 snowflake?
No, not at all. -- /Jacob Carlborg
Sep 29 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/29/2015 11:36 PM, Jacob Carlborg wrote:
 Can't you copy the editable text fields? Or do you want to copy the labels as
well?
I'm not making myself clear. I want to copy any or all of the text in the dialog box using the usual method: click and drag the mouse to pick what I want to copy.
 Can't you copy the whole profile directory?
Thunderbird's most idiotic feature is the profile directory. It's maddeningly stupid, starting with simply finding where Thunderbird put it. Compare with how easy it is to import/export the address book.
Sep 30 2015
prev sibling parent Kagamin <spam here.lot> writes:
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.
Sep 29 2015
prev sibling parent Max Samukha <maxsamukha gmail.com> writes:
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.
Sep 29 2015
prev sibling next sibling parent Kagamin <spam here.lot> writes:
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.
Sep 29 2015
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.)
Sep 29 2015
prev sibling parent reply Brad Anderson <eco gnuk.net> writes:
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
Sep 25 2015
next sibling parent Brad Anderson <eco gnuk.net> writes:
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
Sep 25 2015
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 September 2015 at 09:15, Brad Anderson via Digitalmars-d
<digitalmars-d puremagic.com> 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.
Sep 25 2015