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 ;)



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 ;)




 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

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 

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

 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