February 03, 2019
On Sunday, 3 February 2019 at 11:30:34 UTC, Ecstatic Coder wrote:
> On Sunday, 3 February 2019 at 09:23:59 UTC, rikki cattermole wrote:
>> On 03/02/2019 10:12 PM, Ecstatic Coder wrote:
>>> Using -m32 by default on Windows, while -m64 is the default on Linux and MacOSX, needlessly breaks that cross-platform promise, and thus creates compilation problems that could easily have been avoided by using a consistent behavior across platforms.
>>
>> Keep in mind we are going to be dropping (if I remember correctly) 32-bit support for OSX. So its not quite as simple as the above posts may suggest.
>>
>> Every platform is different, both in hardware in use and in the OS in question. Defaults for targets may not make sense everywhere.
>
> I agree, but IMO this is one more reason to use 64 bit as the new Windows default.
>
> There will always be old PCs running on 32 bit OS, but many statistics corroborate the fact that most Windows users have now switched to the 64 bit version.
>
> That's especially true for PC gamers, if you simply look at the Steam statistics :
>
> https://store.steampowered.com/hwsurvey/
> (click on OS Version)

0.93% have cpus with only 1 core in it. Really shows how people just hold on to their CPU. Would be interesting to see what CPUs are 32-bit and 64-bit Vs. the OS that are 32-bit, but they don't provide that information for CPUs.

It's kind of funny there is someone that would argue that the Windows version of DMD should target 32-bit. This is why Windows is so horrible, people that don't understand or care about the platform making decisions for it. What makes more sense is for the default to be based on the host's OS version, like what LDC does. Doesn't make sense to compile 64-bit on a 32-bit OS as you won't be able to run the program. Which is probably what most people are going to try to do.

February 03, 2019
>> I agree, but IMO this is one more reason to use 64 bit as the new Windows default.
>>
>> There will always be old PCs running on 32 bit OS, but many statistics corroborate the fact that most Windows users have now switched to the 64 bit version.
>>
>> That's especially true for PC gamers, if you simply look at the Steam statistics :
>>
>> https://store.steampowered.com/hwsurvey/
>> (click on OS Version)
>
> As far as I understand, it is technically possible to provide a 64 bit dmd which defaults to x86_64 for windows. The release pipeline needs to adapted. To get this right, this will take several days of work (assumption).
>
> Kind regards
> Andre

That would clearly be the best solution, but just having the -m64 option activated by default on the 32-bit compiler would already be a big step into that direction...

February 03, 2019
> 0.93% have cpus with only 1 core in it. Really shows how people just hold on to their CPU. Would be interesting to see what CPUs are 32-bit and 64-bit Vs. the OS that are 32-bit, but they don't provide that information for CPUs.
>
> It's kind of funny there is someone that would argue that the Windows version of DMD should target 32-bit. This is why Windows is so horrible, people that don't understand or care about the platform making decisions for it. What makes more sense is for the default to be based on the host's OS version, like what LDC does. Doesn't make sense to compile 64-bit on a 32-bit OS as you won't be able to run the program. Which is probably what most people are going to try to do.

+1
February 03, 2019
On Sunday, 3 February 2019 at 15:19:03 UTC, Ecstatic Coder wrote:
>> 0.93% have cpus with only 1 core in it. Really shows how people just hold on to their CPU. Would be interesting to see what CPUs are 32-bit and 64-bit Vs. the OS that are 32-bit, but they don't provide that information for CPUs.
>>
>> It's kind of funny there is someone that would argue that the Windows version of DMD should target 32-bit. This is why Windows is so horrible, people that don't understand or care about the platform making decisions for it. What makes more sense is for the default to be based on the host's OS version, like what LDC does. Doesn't make sense to compile 64-bit on a 32-bit OS as you won't be able to run the program. Which is probably what most people are going to try to do.
>
> +1

Your message doesn't include the author you quote, but i think he referred to my previous message.

"there is someone that would argue that the Windows version of DMD should target 32-bit"

What i meant is that

- DMD32 should target 32 bits binary by default (this is the case)
- DMD64 should target 64 bits binary by default.

Now the yikes is that there's >>no DMD64 officially distributed for windows<<.
And now that -m64 works without the MS build tools, maybe this DMD64 can be released officially ?


February 04, 2019
On Sunday, 3 February 2019 at 14:44:48 UTC, Ron Tarrant wrote:
> On Sunday, 3 February 2019 at 10:49:59 UTC, Andre Pany wrote:
>
>> The environment variable APPDATA points to the roaming folder.
>
> I didn't know that. Thank you, Andre.

Neither did I, but now I do!
February 04, 2019
> but building with 'dub --arch=x86_mscoff' (dmd -m32mscoff) indeed should make dmd use lld if VS isn't available if it's not the case right now.

1. Does not work:

> Running .\vibeApp.exe
> Program exited with code -1073741515

2. And "dub --arch=x86_mscoff" this is expected to be know to new users?

> You can also set the default architecture to x86_64 for all dub projects as described here. .... "defaultArchitecture": "x86_64",

Does not work as dub simply ignore this and gives the same linker error. Because the Windows DMD version is 32bit. So we get 64Bit DMD on 64bit Unix platforms, but getting 32Bit DMD on a 64Bit Windows platform. Makes sense to me.

> Just use the Microsoft linker by passing: -a=x86_mscoff when building using dub.

See above. Does not work

> The linker is already shipped with DMD.

Only works with DMD directly. Dub acts like a inconsistent piece of software that does not know what its parent ( the compiler ) is capable of doing.

> You can install VC++ for 1.5 GB using the Build Tool install.

You are right, my numbers are wrong.

Visual Studio Build Tools 2017 -- 15.9.6
Option Selected: Visual C++ build tools ( default options are W10 SDK, Visual C++ Tools, Test tools )

Total Space required: 4.58GB

Its 1.5GB more then stated i stated before. The 3GB must have been from the last time i installed 2015 version. My bad... Only 4.6GB to install a advised linker.

/Offtopic: And the whole argument about how HD space is cheap, is the same click bait nonsense as why we end up with 20GB operating system, eating 3GB of ram by default, browsers eating gigs for simply display text, Electron ...

Sure, one thing is nothing but when you start stacking up all the moronic "just buy more ram or ssd space or ..." arguments, its pushing the issue of developer incompetence and laziness unto the end users. And we end up with the PCs experience feeling slower then in the past. As CPU and memory gains can not keep up with the wast full development.

> This user experience will attract  a lot of new users.

Not when Dub by default does not work properly on Windows. The fact that we are having a discussion about this, means its not user friendly to the point that getting a simple HTTP Server going, is a struggle.

Any discussion regarding adding build arguments, is a instant "no fly zone" for most new users. Its like talking to grandfathers, sorry, but us millenniums are "spoiled little brats" that have dozens of programming languages available on our fingertips and we can not be bothered wasting hours, days, weeks trying to figure out arcane design decisions. The moment you need more then simple run or build, your already losing to a whole series of language competitors who got their shit together.

Its not because a lot of people here have years of experience build up and know most compiler arguments like some ancient Jedi scriptures, that its a good things. Any basic business manager that is half competent can tell you this.

> Have you even been on the front page? Literally the first example I was met with:

1. That is a ... Tatum ... LINUX EXAMPLE, so its already not platform agnostic path.
2. You think that running a hashbang example is a good introduction to end users?
3. People lean the wrong way and are bypassing the dub package manager

Let me compare to a few languages:

Go: import ( "net/http" ) ...

Ready, set, go ...

Crystal: require "http/server"

Ready, set, go ...

D: Learn package manager ( no example on the front page )
   Figure out why the package manager does not work on Platform W
D: Use example from the front page, that does not work on specific supported platform W
   Example that is also the "wrong" way to run D projects in the future.

I am not here to fight over what is right or wrong. From the looks people are already set in their ways with years of experience. This is my personal experience with D and the issue points that the language has. Its like a billionaire not understanding why people simply do not get a loan during the shutdown.

And here is another fun one:

> C:\Users\Ben\AppData\Local\dub\packages\vibe-d-0.8.4\vibe-d\mongodb\vibe\db\mongo\settings.d(16,8): Deprecation: alias `std.digest.digest.toHexString` is deprecated - import std.digest instead of std.digest.digest. std.digest.digest will be removed in 2.084
> dmd --version
> DMD32 D Compiler v2.084.0

What is wrong here? :)

Not counting the dozens of warnings that show up when trying to compile Vibe.D from deprecated functions. I call this a very bad introduction in a project but that is Vibe.d its issue, not D as a language but people will not differ.

The fact that we have a warning informing us that this deprecated and will be gone in 2.084 but DMD is 2.084.

And all these posts later and vibe.d is still as dead in the water as it was before. Experience: C-

My advice: Simply dump DMD Windows because if you can not support it to work correctly, then do not support it at all.
February 05, 2019
On Monday, 4 February 2019 at 23:28:51 UTC, Ben wrote:
>> [...]
>
> 1. Does not work:
>
>> [...]
>
> 2. And "dub --arch=x86_mscoff" this is expected to be know to new users?
>
> [...]

There are several points addressed in you post.

1) Please provide a reproducible example for Program exited with code -1073741515

2) My expectation is, x86_mscoff will become the default for 32 Bit dmd, while
x86_64 will become the default for 64 bit dmd. Hopefully this year.
The hard work of some fantastic people made this possible.

3) Setting default architecture in dub settings file should work and can be overwritten
with command line arg --arch. If it is not working please provide details.

4) vibe-d example is working fine on my windows computer. The shebang line
is just ignored. But you are right, it should be removed. If it is not working
please provide details.

5) The warning for mongodb is already fixed (https://github.com/vibe-d/vibe.d/commit/07599b09b5d0404d7dc64db4696c722ec637db77#diff-a8cdd5513604e73687c443113cd17a9b)

Kind regards
André



February 05, 2019
On Monday, 4 February 2019 at 23:28:51 UTC, Ben wrote:
> 1. That is a ... Tatum ... LINUX EXAMPLE, so its already not platform agnostic path.
> 2. You think that running a hashbang example is a good introduction to end users?
> 3. People lean the wrong way and are bypassing the dub package manager
>
> Let me compare to a few languages:
>
> Go: import ( "net/http" ) ...
>
> Ready, set, go ...
>
> Crystal: require "http/server"
>
> Ready, set, go ...

My 2 cents:
The comparison cith Go holds, but comparing D with Crystal is invalid if you are talking about Windows issues; since Crystal isn't natively available on Windows.
February 05, 2019
On Monday, 4 February 2019 at 23:28:51 UTC, Ben wrote:
>> but building with 'dub --arch=x86_mscoff' (dmd -m32mscoff) indeed should make dmd use lld if VS isn't available if it's not the case right now.
>
> ... <snip>


I couldn't agree more. I am trying to expand using D from a simple 1 file scripts to bigger applications, but its always a struggle. Programming is not my day job, but I use it occasionally for my job related work.

Funny thing is after reading all these emails I am still confused how to get vibe.d working on windows. Could somebody create a step-by-step instructions with an example that actually works? Pretty please? Thanks in advance.



February 05, 2019
On Monday, 4 February 2019 at 23:28:51 UTC, Ben wrote:
> Visual Studio Build Tools 2017 -- 15.9.6
> Option Selected: Visual C++ build tools ( default options are W10 SDK, Visual C++ Tools, Test tools )
>
> Total Space required: 4.58GB

You don't need W10 SDK for the linker or any of the other options. Just cause they are default options does not mean you need them. Hint: you can uncheck the checkmark unless it is greyed out. When you uncheck all the options except for the one you can't (the one with the linker) you will be left with 1.5 GB :).