On Monday, 14 November 2016 at 16:59:56 UTC, Nick Sabalausky wrote:
> SSDs are still far too small.

Hmm...

http://arstechnica.com/gadgets/2016/08/seagate-unveils-60tb-ssd-the-worlds-largest-hard-drive/

> the ONLY time I ever have speed issues

"Speed issues" is one thing. Having most operations be INSTANT is another. It MASSIVELY transforms your workflow; UIs where each key press launches a command (e.g. magit, background builds...) become sensible and usable "blindly", and can easily multiply productivity by an order of magnitude.

If you don't have an SSD in your work machine (but can afford one), you simply don't value your time.

On Monday, 14 November 2016 at 13:44:29 UTC, Patrick Schluter wrote:
> That's a true issue imho also. I had the same problem. Both my machine at work and at home have their windows system partition on a smallish SSD.

You can move stuff from the system drive with symbolic links; e.g. windows\installer, just see what takes space and has no reason to be on the system drive.

On Tuesday, 15 November 2016 at 08:33:26 UTC, Vladimir Panteleev wrote:
> UIs where each key press launches a command (e.g. magit, background builds...)

emacs?
Also doesn't dmdfe spend most of its time in semantic analysis? You can't possibly optimize that with IO.

On Tuesday, 15 November 2016 at 09:02:08 UTC, Kagamin wrote:
> On Tuesday, 15 November 2016 at 08:33:26 UTC, Vladimir Panteleev wrote:
>> UIs where each key press launches a command (e.g. magit, background builds...)
>
> emacs?

Yep.

> Also doesn't dmdfe spend most of its time in semantic analysis?

Yep, but this isn't restricted to D, of course. More complicated build systems do a lot of I/O (and, often, unnecessary sync()ing).

On Monday, 14 November 2016 at 10:20:48 UTC, Kagamin wrote:
> On Monday, 14 November 2016 at 09:51:39 UTC, John Colvin wrote:
>> Now there is http://landinghub.visualstudio.com/visual-cpp-build-tools, perhaps we should be encouraging using that instead?
>
> It's still 3gb, so one might want to delete unneeded stuff after installation, like arm tools and cross compilers.

Are there plans to write a homebrew 64-bit linker for DMD?

To this question I would appreciate an answer from the people who develop DMD itself and its 32-bit linker.

On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:
> Are there plans to write a homebrew 64-bit linker for DMD?

There are already ld from mingw and lld from llvm team.

On Tuesday, 15 November 2016 at 11:28:16 UTC, Kagamin wrote:
> On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:
>> Are there plans to write a homebrew 64-bit linker for DMD?
>
> There are already ld from mingw and lld from llvm team.

Why aren't they used and distributed in DMD for Windows by default?

If the tools mentioned above (LD and LLD) are available and usable on Windows x64 instead of the ones provided in heavily bloated packages by Microsoft, how come the DMD installer for Windows doesn't offer them as an alternative (or better yet as the default)?

Dne 15.11.2016 v 14:23 AB via Digitalmars-d napsal(a):

> On Tuesday, 15 November 2016 at 11:28:16 UTC, Kagamin wrote:
>> On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:
>>> Are there plans to write a homebrew 64-bit linker for DMD?
>>
>> There are already ld from mingw and lld from llvm team.
>
> Why aren't they used and distributed in DMD for Windows by default?
>
> If the tools mentioned above (LD and LLD) are available and usable on Windows x64 instead of the ones provided in heavily bloated packages by Microsoft, how come the DMD installer for Windows doesn't offer them as an alternative (or better yet as the default)?
>
AFAIK ld on mingw can`t link against mscoff file format so it is not very usable. LLD is quite new so I do not know how production ready is. But I believe LLD will be the answer in future.

Btw. today I want to start working on a D project in work, but I cant, because there is not enoght space on C:\ partion and there is not possible to instal VS to another disk :( (Ok in few attempt of installing VS there has been path I can change but it does not work anyway, still VS is trying to install to C:\ ).

So maybe one day I will be able to work at job on D windows project. Fortunately I can still work on other part (still in D) of project which is running on linux

On Tuesday, 15 November 2016 at 13:23:38 UTC, AB wrote:
> On Tuesday, 15 November 2016 at 11:28:16 UTC, Kagamin wrote:
>> On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:
>>> Are there plans to write a homebrew 64-bit linker for DMD?
>>
>> There are already ld from mingw and lld from llvm team.
>
> Why aren't they used and distributed in DMD for Windows by default?
>
> If the tools mentioned above (LD and LLD) are available and usable on Windows x64 instead of the ones provided in heavily bloated packages by Microsoft, how come the DMD installer for Windows doesn't offer them as an alternative (or better yet as the default)?

It's not just the linker. You need the libs as well (static and dynamic ones), and not just the WinSDK ones, but the MSVCRT ones too. Just use the Visual C++ Build Tools if there's not enough disk space in 2016 *cough*. IMO there's just no way of doing professional Windows development without the MS toolchain. And no reason to complain about it just because most Linux distros come with a fully fledged development ecosystem.

On Tuesday, 15 November 2016 at 16:00:48 UTC, kink wrote:
> It's not just the linker. You need the libs as well (static and dynamic ones), and not just the WinSDK ones, but the MSVCRT ones too.

I was under the impression that DMD for Windows was (meant to be) self-sufficient. I must have been misled by how it can build 32-bit applications just fine without requiring the many gigabytes of WinSDK and MSVCRT extras.

Hopefully, future releases of DMD will fix this inconsistency by requiring Visual Studio for 32-bit D programs as well.