www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The issue with D...

reply Ben <benny.luypaert rhysoft.com> writes:
Not to be a downer but just trying out D again with Vibe.d and 
getting confronted with the typical bug: Unexpected OPTLINK 
Termination at EIP=0040F60A

Tracing this back, bring up issues in the bugtracker from 2017 ( 
17508 ), that is still open.

First impressions and such matter. And for some reason ever new 
"first impression" with D seems to result in annoying bugs being 
discovered ( Windows 10 ).

Yes, i already know. No Visual Studio linker installed ( and no, 
i do not want a 3GB installation just for the linker, when DMD 
already includes it ). But somebody forgot to tell dub!

So anybody using Vibe.d or any other project that rely on dub 
figuring out that DMD can be run without Visual Studios linker, 
can enjoy very nice and cryptic errors. User friendly it is not.

/Frustrated that this is still a issue.
Feb 01 2019
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Saturday, 2 February 2019 at 02:32:28 UTC, Ben wrote:

 Not to be a downer but just trying out D again with Vibe.d and 
 getting confronted with the typical bug: Unexpected OPTLINK 
 Termination at EIP=0040F60A
 ...
 Yes, i already know. No Visual Studio linker installed ( and 
 no, i do not want a 3GB installation just for the linker, when 
 DMD already includes it ). But somebody forgot to tell dub!
 ...


This isn't dub or D problem, normally dub shouldn't know about 
linker, so you can set compiler flag to tell which linker to 
use(if there is such for dmd...) from dub project.

The actual problem in this case is DMD defaulting to old object 
file format/pipeline, 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. Because even if you 
tell dmd -m32 to use lld it probably won't work because it 
produce stuff for OPTLINK for that target.

There is rumors about making the COFF default format when all 
major issues with lld will be ironed out.
Feb 01 2019
parent reply Ben <benny.luypaert rhysoft.com> writes:
 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\mon
o\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.
Feb 04 2019
next sibling parent Andre Pany <andre s-e-a-p.de> writes:
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é
Feb 04 2019
prev sibling next sibling parent reply Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:
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.
Feb 05 2019
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Tuesday, 5 February 2019 at 10:47:36 UTC, Laurent Tréguier 
wrote:

 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.


Indeed, but the problem remains.

Using D for server and GUI development should appear easy and 
natural.

The current vibe.d examples isn't conveying that, with all its 
"black magic" comments.

Contrarily to what D's "leadership" thinks, D has the potential 
to become a very good competitor to Go and Crystal for server 
development, as both of them are also performant garbage 
collected languages.

And with dlangui, developing connected desktop application is a 
real pleasure.

D should be promoted for what it does best, and should how 
complex application can be made easily and efficiently with 
simple code.
Feb 07 2019
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 7 February 2019 at 08:26:50 UTC, Ecstatic Coder 
wrote:

 On Tuesday, 5 February 2019 at 10:47:36 UTC, Laurent Tréguier 
 wrote:

 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.


 Indeed, but the problem remains.

 Using D for server and GUI development should appear easy and 
 natural.

 The current vibe.d examples isn't conveying that, with all its 
 "black magic" comments.

 Contrarily to what D's "leadership" thinks, D has the potential 
 to become a very good competitor to Go and Crystal for server 
 development, as both of them are also performant garbage 
 collected languages.

 And with dlangui, developing connected desktop application is a 
 real pleasure.

 D should be promoted for what it does best, and should how 
 complex application can be made easily and efficiently with 
 simple code.


 From your post I am not sure whether you know the purpose of the 
comments in the vibe.d example.

The dub.sdl comment is a dub single package descriptor. You can 
save the lines to a file example.d and run it with command: dub 
example.d

With latest dub you can even save the file without the extension 
.d and if you are on a Linux system you can execute it just with 
command: ./example. That this the purpose of the shebang line.

I would not describe it as black magic but as very convenient way 
of calling D coding.
Vibe.d does here a very good job and just leverage features of 
posix os and features of the dub package manager.

Kind regards
Andre
Feb 07 2019
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Thursday, 7 February 2019 at 11:51:37 UTC, Andre Pany wrote:

 On Thursday, 7 February 2019 at 08:26:50 UTC, Ecstatic Coder 
 wrote:

 On Tuesday, 5 February 2019 at 10:47:36 UTC, Laurent Tréguier 
 wrote:

 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.


 Indeed, but the problem remains.

 Using D for server and GUI development should appear easy and 
 natural.

 The current vibe.d examples isn't conveying that, with all its 
 "black magic" comments.

 Contrarily to what D's "leadership" thinks, D has the 
 potential to become a very good competitor to Go and Crystal 
 for server development, as both of them are also performant 
 garbage collected languages.

 And with dlangui, developing connected desktop application is 
 a real pleasure.

 D should be promoted for what it does best, and should how 
 complex application can be made easily and efficiently with 
 simple code.


 From your post I am not sure whether you know the purpose of 
 the comments in the vibe.d example.

 The dub.sdl comment is a dub single package descriptor. You can 
 save the lines to a file example.d and run it with command: dub 
 example.d

 With latest dub you can even save the file without the 
 extension .d and if you are on a Linux system you can execute 
 it just with command: ./example. That this the purpose of the 
 shebang line.

 I would not describe it as black magic but as very convenient 
 way of calling D coding.
 Vibe.d does here a very good job and just leverage features of 
 posix os and features of the dub package manager.

 Kind regards
 Andre


Don't get me wrong.

I'm not saying that including dub commands into D source code 
can't be convenient.

I'm just saying that when you show only one example on the 
landing page of a programming language, it'd better be crystal 
clear.

Or people will see this "complication" as the norm with this 
language.

It's just a matter of public perception.

As you know, I'm personally in favor of showing **THREE** 
**SIMPLE** **USEFUL** examples :

1. how to declare/initialize/process an array and 
read/write/split/replace stuff in a text file
2. how to make a "hello world" http web server
3. how to open a window, enter some text, and say "hello xxx" 
when you push a "hello" button

Simple, easy and concise code.

I'm VERY happy there is a web server example on D's landing page. 
I mean it.

But removing this sort of "garbage" comment, as useful as it is, 
would probably make the example more pleasant to read for people 
evaluating the interest of using D for their next 
personal/professionnal project...
Feb 07 2019
parent reply Seb <seb wilzba.ch> writes:
On Thursday, 7 February 2019 at 18:18:16 UTC, Ecstatic Coder 
wrote:

 Simple, easy and concise code.

 I'm VERY happy there is a web server example on D's landing 
 page. I mean it.

 But removing this sort of "garbage" comment, as useful as it 
 is, would probably make the example more pleasant to read for 
 people evaluating the interest of using D for their next 
 personal/professionnal project...


Do you mind if I ask how the current example is dark magic for 
you?
How would you/we make it better?
Feb 07 2019
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Thursday, 7 February 2019 at 20:22:17 UTC, Seb wrote:

 On Thursday, 7 February 2019 at 18:18:16 UTC, Ecstatic Coder 
 wrote:

 Simple, easy and concise code.

 I'm VERY happy there is a web server example on D's landing 
 page. I mean it.

 But removing this sort of "garbage" comment, as useful as it 
 is, would probably make the example more pleasant to read for 
 people evaluating the interest of using D for their next 
 personal/professionnal project...


 Do you mind if I ask how the current example is dark magic for 
 you?
 How would you/we make it better?


Stupid simple :

void main()
{
     import vibe.d;
     listenHTTP(":8080", (req, res) {
         res.writeBody("Hello, World: " ~ req.path);
     });
     runApplication();
}

Not stupid simple :


/+ dub.sdl:
name "hello_vibed"
dependency "vibe-d" version="~>0.8.0"
+/
void main()
{
     import vibe.d;
     listenHTTP(":8080", (req, res) {
         res.writeBody("Hello, World: " ~ req.path);
     });
     runApplication();
}

It's just pure cosmetics. But as with everything, "how it looks" 
is something that matter.

If I arrive at a professional IT appointment with my customer 
with a three day beard and my jogging clothes, he won't judge me 
the same as if I'm shaved and with my suit and tie.

When you are evaluating a programming language, the first lines 
of code you see give you a good or bad impression about it. And 
in all matters it's always better to give a good impression from 
the start.

I guess some people are very fond of cryptic languages with 
esoteric syntaxes, etc. But honestly I'm not sure it's the norm, 
and that most people dislike simple, crystal clear code.
Feb 07 2019
parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Thursday, 7 February 2019 at 20:49:31 UTC, Ecstatic Coder 
wrote:

 On Thursday, 7 February 2019 at 20:22:17 UTC, Seb wrote:

 On Thursday, 7 February 2019 at 18:18:16 UTC, Ecstatic Coder 
 wrote:

 [...]


 Do you mind if I ask how the current example is dark magic for 
 you?
 How would you/we make it better?


 Stupid simple :

 void main()
 {
     import vibe.d;
     listenHTTP(":8080", (req, res) {
         res.writeBody("Hello, World: " ~ req.path);
     });
     runApplication();
 }

 Not stupid simple :


 /+ dub.sdl:
 name "hello_vibed"
 dependency "vibe-d" version="~>0.8.0"
 +/
 void main()
 {
     import vibe.d;
     listenHTTP(":8080", (req, res) {
         res.writeBody("Hello, World: " ~ req.path);
     });
     runApplication();
 }

 It's just pure cosmetics. But as with everything, "how it 
 looks" is something that matter.

 If I arrive at a professional IT appointment with my customer 
 with a three day beard and my jogging clothes, he won't judge 
 me the same as if I'm shaved and with my suit and tie.

 When you are evaluating a programming language, the first lines 
 of code you see give you a good or bad impression about it. And 
 in all matters it's always better to give a good impression 
 from the start.

 I guess some people are very fond of cryptic languages with 
 esoteric syntaxes, etc. But honestly I'm not sure it's the 
 norm, and that most people dislike simple, crystal clear code.


Is it pure cosmetics? I thought the whole point of the dub 
comment was so that you could just run "dub server.d" and it 
would just work?

In your super simple example, it won't just work, you need to do 
to the whole dub fetch/build thing. Not saying it's a bad thing, 
but we are talking about first impressions, and I can see 
pros/cons to both approaches.

Jordan
Feb 07 2019
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 07, 2019 at 09:27:47PM +0000, Jordan Wilson via Digitalmars-d wrote:

 On Thursday, 7 February 2019 at 20:49:31 UTC, Ecstatic Coder wrote:


[...]

 Stupid simple :
 
 void main()
 {
     import vibe.d;
     listenHTTP(":8080", (req, res) {
         res.writeBody("Hello, World: " ~ req.path);
     });
     runApplication();
 }
 
 Not stupid simple :
 

 /+ dub.sdl:
 name "hello_vibed"
 dependency "vibe-d" version="~>0.8.0"
 +/
 void main()
 {
     import vibe.d;
     listenHTTP(":8080", (req, res) {
         res.writeBody("Hello, World: " ~ req.path);
     });
     runApplication();
 }




[...]

 Is it pure cosmetics? I thought the whole point of the dub comment was
 so that you could just run "dub server.d" and it would just work?
 
 In your super simple example, it won't just work, you need to do to
 the whole dub fetch/build thing. Not saying it's a bad thing, but we
 are talking about first impressions, and I can see pros/cons to both
 approaches.


[...]

I think his point is that whatever effect is triggered by the dub
comment should be made the *default* behaviour, such that you don't need
to type out any of it explicitly and the compiler/toolchain/whatever
will just Do It(tm), whatever It may be.  The current default is that it
will not work if the dub comment isn't there.  His argument is that this
default should be changed so that it *does* work.  In theory, dub
"should" be able to detect the "import vibe.d" line and from there
figure out what to do "automatically".

I'm unsure whether I agree with him, though.  In order to pull this off,
dub will have to implement heuristics for detecting VibeD imports and
somehow map that to the requisite vibe-d dependency declaration.  I'm
uncertain I'm entirely comfortable with this kind of IMO hackish
implementation that may end up interacting badly with other things once
you get beyond trivial projects.

But regardless, he certainly has a point in making things work
out-of-the-box with minimal effort, even if we may disagree on just how
minimal this minimal effort should be.  Not everyone is a masochistic
programmer like myself who would shun such niceties and prefer manually
compiling and linking stuff on the command-line. (This is why it'd
probably be a bad idea to put me on the marketing / UI design team.
:-P)


T

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.
Feb 07 2019
next sibling parent Jordan Wilson <wilsonjord gmail.com> writes:
On Thursday, 7 February 2019 at 21:47:07 UTC, H. S. Teoh wrote:

 On Thu, Feb 07, 2019 at 09:27:47PM +0000, Jordan Wilson via 
 Digitalmars-d wrote:

 [...]


 [...]

 [...]




 [...]

 [...]


 [...]

 I think his point is that whatever effect is triggered by the 
 dub comment should be made the *default* behaviour, such that 
 you don't need to type out any of it explicitly and the 
 compiler/toolchain/whatever will just Do It(tm), whatever It 
 may be.  The current default is that it will not work if the 
 dub comment isn't there.  His argument is that this default 
 should be changed so that it *does* work.  In theory, dub 
 "should" be able to detect the "import vibe.d" line and from 
 there figure out what to do "automatically".

 I'm unsure whether I agree with him, though.  In order to pull 
 this off, dub will have to implement heuristics for detecting 
 VibeD imports and somehow map that to the requisite vibe-d 
 dependency declaration.  I'm uncertain I'm entirely comfortable 
 with this kind of IMO hackish implementation that may end up 
 interacting badly with other things once you get beyond trivial 
 projects.

 But regardless, he certainly has a point in making things work 
 out-of-the-box with minimal effort, even if we may disagree on 
 just how minimal this minimal effort should be.  Not everyone 
 is a masochistic programmer like myself who would shun such 
 niceties and prefer manually compiling and linking stuff on the 
 command-line. (This is why it'd probably be a bad idea to put 
 me on the marketing / UI design team. :-P)


 T


Ah I see.

I pretty much started using dub because I was sick of manually 
dealing with includes/libs from within my previous IDE, and 
thought the ability to simply put dependency "vibe-d" 
version="~>0.8.4" in my project and be done was great; the 
thought of even more automagic convenience didn't even occur to 
me!

Jordan
Feb 07 2019
prev sibling parent Wyatt <wyatt.epp gmail.com> writes:
On Thursday, 7 February 2019 at 21:47:07 UTC, H. S. Teoh wrote:

 I think his point is that whatever effect is triggered by the 
 dub comment should be made the *default* behaviour


I'm pretty sure it's just that it looks messy because of the dub 
stuff (which isn't _strictly_ necessary).  I honestly kind of 
agree.

Sure, removing it would remove your ability to just paste it in a 
file and run it, but... do people actually do that?

I wonder if it'd be helped by putting a comment explaining the 
top matter?  Or link to a "runnable" version?

-Wyatt
Feb 07 2019
prev sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Thursday, 7 February 2019 at 21:27:47 UTC, Jordan Wilson wrote:

 On Thursday, 7 February 2019 at 20:49:31 UTC, Ecstatic Coder 
 wrote:

 On Thursday, 7 February 2019 at 20:22:17 UTC, Seb wrote:

 On Thursday, 7 February 2019 at 18:18:16 UTC, Ecstatic Coder 
 wrote:

 [...]


 Do you mind if I ask how the current example is dark magic 
 for you?
 How would you/we make it better?


 Stupid simple :

 void main()
 {
     import vibe.d;
     listenHTTP(":8080", (req, res) {
         res.writeBody("Hello, World: " ~ req.path);
     });
     runApplication();
 }

 Not stupid simple :


 /+ dub.sdl:
 name "hello_vibed"
 dependency "vibe-d" version="~>0.8.0"
 +/
 void main()
 {
     import vibe.d;
     listenHTTP(":8080", (req, res) {
         res.writeBody("Hello, World: " ~ req.path);
     });
     runApplication();
 }

 It's just pure cosmetics. But as with everything, "how it 
 looks" is something that matter.

 If I arrive at a professional IT appointment with my customer 
 with a three day beard and my jogging clothes, he won't judge 
 me the same as if I'm shaved and with my suit and tie.

 When you are evaluating a programming language, the first 
 lines of code you see give you a good or bad impression about 
 it. And in all matters it's always better to give a good 
 impression from the start.

 I guess some people are very fond of cryptic languages with 
 esoteric syntaxes, etc. But honestly I'm not sure it's the 
 norm, and that most people dislike simple, crystal clear code.


 Is it pure cosmetics? I thought the whole point of the dub 
 comment was so that you could just run "dub server.d" and it 
 would just work?

 In your super simple example, it won't just work, you need to 
 do to the whole dub fetch/build thing. Not saying it's a bad 
 thing, but we are talking about first impressions, and I can 
 see pros/cons to both approaches.

 Jordan


I agree. I've already had this discussion about that same http 
stuff being installed by default in Go and Crystal, but not in D, 
despite D already has support by default for json, sqlite, etc.

And very honestly, preinstalling dlangui to allow people to 
immediately start developing connected applications (like in 
Python and Red) after the DMD installation could also help D 
become by far the best alternative to both Go and Python.

But I know this won't happen, because D's leadership, instead of 
focusing on D's strengths, tries for a decade to compete with 
C/C++ (low level no-GC languages), and clearly not Go, Python, 
etc (high-level languages for web/gui/scripting).

Just my two cents...
Feb 08 2019
next sibling parent reply JN <666total wp.pl> writes:
On Friday, 8 February 2019 at 12:09:20 UTC, Ecstatic Coder wrote:

 I agree. I've already had this discussion about that same http 
 stuff being installed by default in Go and Crystal, but not in 
 D, despite D already has support by default for json, sqlite, 
 etc.

 And very honestly, preinstalling dlangui to allow people to 
 immediately start developing connected applications (like in 
 Python and Red) after the DMD installation could also help D 
 become by far the best alternative to both Go and Python.

 But I know this won't happen, because D's leadership, instead 
 of focusing on D's strengths, tries for a decade to compete 
 with C/C++ (low level no-GC languages), and clearly not Go, 
 Python, etc (high-level languages for web/gui/scripting).

 Just my two cents...


While I agree with you on the silliness in chasing C/C++, I 
disagree with the rest. I don't think adding a package is such a 
big deal. And you don't have to run dub fetch, dub build/run will 
do that for you, and the IDE can handle that too. It's just 
people have a fear of dub and try to avoid it in favor of 
makefiles whenever possible.

I took a look at the competition. I googled "rust web server" and 
got this result: 
https://gist.github.com/mjohnsullivan/e5182707caf0a9dbdf2d . To 
be honest, the code doesn't look too nice, it's too low-level and 
it's not something one would write in a hurry. On the bottom 
though is an example using external packages and it looks very 
nice. I think things like sockets, xml, json belong to standard 
library, because it promotes interoperability (imagine if we 
didn't have string in stdlib and everyone would make their custom 
string classes, it'd be a mess). Dlangui - no. At most it should 
be promoted as a most straighforward way to do GUIs with D. But 
even then, I have doubts. I've never used this library, but the 
screenshots give me a very non-native GUI feeling. In theory it 
looks fine, but it just looks off.
Feb 08 2019
next sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 8 February 2019 at 12:29:57 UTC, JN wrote:

 On Friday, 8 February 2019 at 12:09:20 UTC, Ecstatic Coder 
 wrote:

 I agree. I've already had this discussion about that same http 
 stuff being installed by default in Go and Crystal, but not in 
 D, despite D already has support by default for json, sqlite, 
 etc.

 And very honestly, preinstalling dlangui to allow people to 
 immediately start developing connected applications (like in 
 Python and Red) after the DMD installation could also help D 
 become by far the best alternative to both Go and Python.

 But I know this won't happen, because D's leadership, instead 
 of focusing on D's strengths, tries for a decade to compete 
 with C/C++ (low level no-GC languages), and clearly not Go, 
 Python, etc (high-level languages for web/gui/scripting).

 Just my two cents...


 While I agree with you on the silliness in chasing C/C++, I 
 disagree with the rest. I don't think adding a package is such 
 a big deal. And you don't have to run dub fetch, dub build/run 
 will do that for you, and the IDE can handle that too. It's 
 just people have a fear of dub and try to avoid it in favor of 
 makefiles whenever possible.

 I took a look at the competition. I googled "rust web server" 
 and got this result: 
 https://gist.github.com/mjohnsullivan/e5182707caf0a9dbdf2d . To 
 be honest, the code doesn't look too nice, it's too low-level 
 and it's not something one would write in a hurry. On the 
 bottom though is an example using external packages and it 
 looks very nice. I think things like sockets, xml, json belong 
 to standard library, because it promotes interoperability 
 (imagine if we didn't have string in stdlib and everyone would 
 make their custom string classes, it'd be a mess). Dlangui - 
 no. At most it should be promoted as a most straighforward way 
 to do GUIs with D. But even then, I have doubts. I've never 
 used this library, but the screenshots give me a very 
 non-native GUI feeling. In theory it looks fine, but it just 
 looks off.


I'm not saying that adding a package is a big deal. I'm a VERY 
happy user of Dub.

In just two lines it can create my dlangui project, compile it 
and run it.

I'm simply saying that nowadays many languages (Go, Python, etc) 
which appear to be more "popular" than D come with preinstalled 
web or gui libraries, and that **maybe** this helps them in 
convincing people to use them for this kind of development.

Like them, D also has a very extensive standard library, but 
doesn't see the interest in having some basic http server classes 
provided by default, which I regularly regret.
Feb 08 2019
parent reply JN <666total wp.pl> writes:
On Friday, 8 February 2019 at 21:42:18 UTC, Ecstatic Coder wrote:

 I'm simply saying that nowadays many languages (Go, Python, 
 etc) which appear to be more "popular" than D come with 
 preinstalled web or gui libraries, and that **maybe** this 
 helps them in convincing people to use them for this kind of 
 development.

 Like them, D also has a very extensive standard library, but 
 doesn't see the interest in having some basic http server 
 classes provided by default, which I regularly regret.


Perhaps. But for example when it comes to GUI, Python only comes 
preinstalled with Tk, which isn't exactly the best GUI library 
available. Go doesn't come with anything. I think what these 
languages do better is messaging on what libraries are available. 
Rust notably has the are we X websites: 
https://www.arewewebyet.org/ http://areweguiyet.com/ 
http://arewegameyet.com . In case of Python and Go, there's 
usually a one defacto unofficial library for every usecase. With 
D it's a bit trickier. Imagine you want to use a XML library. 
First try - std.xml. But everyone tells you it sucks and even 
documentation says it's not the best. So you try external 
packages. You type "xml" in package search. That doesn't work too 
good: http://code.dlang.org/search?q=xml . After some more 
searching you learn about std-experimental-xml, dxml, kxml. 
std-experimental-xml and kxml I don't even know if they work with 
recent D versions. dxml seems to work, although I don't know if 
it's considered release ready already. Similar story for other 
libraries, especially json, or mysql wrappers.

I don't think having all that stuff built-in is an advantage, but 
knowing where to look definitely is.
Feb 08 2019
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 8 February 2019 at 21:59:45 UTC, JN wrote:

 On Friday, 8 February 2019 at 21:42:18 UTC, Ecstatic Coder 
 wrote:

 I'm simply saying that nowadays many languages (Go, Python, 
 etc) which appear to be more "popular" than D come with 
 preinstalled web or gui libraries, and that **maybe** this 
 helps them in convincing people to use them for this kind of 
 development.

 Like them, D also has a very extensive standard library, but 
 doesn't see the interest in having some basic http server 
 classes provided by default, which I regularly regret.


 Perhaps. But for example when it comes to GUI, Python only 
 comes preinstalled with Tk, which isn't exactly the best GUI 
 library available. Go doesn't come with anything. I think what 
 these languages do better is messaging on what libraries are 
 available. Rust notably has the are we X websites: 
 https://www.arewewebyet.org/ http://areweguiyet.com/ 
 http://arewegameyet.com . In case of Python and Go, there's 
 usually a one defacto unofficial library for every usecase. 
 With D it's a bit trickier. Imagine you want to use a XML 
 library. First try - std.xml. But everyone tells you it sucks 
 and even documentation says it's not the best. So you try 
 external packages. You type "xml" in package search. That 
 doesn't work too good: http://code.dlang.org/search?q=xml . 
 After some more searching you learn about std-experimental-xml, 
 dxml, kxml. std-experimental-xml and kxml I don't even know if 
 they work with recent D versions. dxml seems to work, although 
 I don't know if it's considered release ready already. Similar 
 story for other libraries, especially json, or mysql wrappers.

 I don't think having all that stuff built-in is an advantage, 
 but knowing where to look definitely is.


I agree, but providing the same basic building blocks has allowed 
the Crystal and Go to buid LOTS of GREAT web frameworks.

And yes, after you can decide if you also want to use one of them 
for your big web app or directly use those same buildings blocks 
for your tiny web app.

For instance, I'm currently using Chi as Go web framework, and 
its source code is ridiculously small in size, with almost no 
dependencies. Those are two reasons why we are so many to love it.

Same reasons for the incredible success of Kemal in the Crystal 
community. Small code, almost no dependencies.

But in both languages there are MANY other great alternatives, 
also mainly or exclusively based on the standard http classes.

So having less choice might be a very good thing as well, but 
personally I still prefer to have the opportunity to choose what 
suits me best among a large panel of great solutions.
Feb 10 2019
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 8 February 2019 at 12:29:57 UTC, JN wrote:

 On Friday, 8 February 2019 at 12:09:20 UTC, Ecstatic Coder 
 wrote:

 [...]


 I took a look at the competition. I googled "rust web server" 
 and got this result: 
 https://gist.github.com/mjohnsullivan/e5182707caf0a9dbdf2d . To 
 be honest, the code doesn't look too nice, it's too low-level 
 and it's not something one would write in a hurry. On the 
 bottom though is an example using external packages and it 
 looks very nice. I think things like sockets, xml, json belong 
 to standard library, because it promotes interoperability 
 (imagine if we didn't have string in stdlib and everyone would 
 make their custom string classes, it'd be a mess). Dlangui - 
 no. At most it should be promoted as a most straighforward way 
 to do GUIs with D. But even then, I have doubts. I've never 
 used this library, but the screenshots give me a very 
 non-native GUI feeling. In theory it looks fine, but it just 
 looks off.


Microsoft is using Actix for their Rust Azure backend projects, a 
bit more powerful and easier to use than that gist.

https://actix.rs/
Feb 08 2019
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2019-02-08 13:29, JN wrote:


 I took a look at the competition. I googled "rust web server" and got 
 this result: https://gist.github.com/mjohnsullivan/e5182707caf0a9dbdf2d 
 . To be honest, the code doesn't look too nice, it's too low-level and 
 it's not something one would write in a hurry.


I don't know Rust, but that doesn't look like HTTP, it looks like a 
socket example. It's possible to do the same in D, with roughly the same 
amount of code, using only the standard library.

-- 
/Jacob Carlborg
Feb 12 2019
prev sibling parent reply 0xEAB <desisma heidel.beer> writes:
On Friday, 8 February 2019 at 12:09:20 UTC, Ecstatic Coder wrote:

 And very honestly, preinstalling dlangui


What qualifies DlangUI to become the default GUI lib that should 
be pre-installed (in terms of: what disqualifies other libs)?


  - Elias
Feb 09 2019
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Sunday, 10 February 2019 at 01:13:16 UTC, 0xEAB wrote:

 On Friday, 8 February 2019 at 12:09:20 UTC, Ecstatic Coder 
 wrote:

 And very honestly, preinstalling dlangui


 What qualifies DlangUI to become the default GUI lib that 
 should be pre-installed (in terms of: what disqualifies other 
 libs)?


  - Elias


Just try them all, and you will quickly find which one is the 
most cross-platform, compiles easily, runs fast on all the 
platforms, behaves the same everywhere, can use 3D or canvas 
rendering, has small dependencies, can be easily mixed with 3D 
rendering too and gets the job done with crystal clear code.

Gtkd, tkd, etc are all good, but as you guess my personal 
favorite one is obviously dlangui, for all the reasons above...
Feb 10 2019
next sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Sunday, 10 February 2019 at 10:22:07 UTC, Ecstatic Coder wrote:

 On Sunday, 10 February 2019 at 01:13:16 UTC, 0xEAB wrote:

 On Friday, 8 February 2019 at 12:09:20 UTC, Ecstatic Coder 
 wrote:

 And very honestly, preinstalling dlangui


 What qualifies DlangUI to become the default GUI lib that 
 should be pre-installed (in terms of: what disqualifies other 
 libs)?


  - Elias


 Just try them all, and you will quickly find which one is the 
 most cross-platform, compiles easily, runs fast on all the 
 platforms, behaves the same everywhere, can use 3D or canvas 
 rendering, has small dependencies, can be easily mixed with 3D 
 rendering too and gets the job done with crystal clear code.

 Gtkd, tkd, etc are all good, but as you guess my personal 
 favorite one is obviously dlangui, for all the reasons above...


There is only a small enhancement missing in dub to allow 
following command:

dub init example -t dlangui

This will create a new dlangui example package on your local file 
system which you can then immediately run with command dub.
With this enhancement in place for me it seems there is no reason 
to include any specific ui toolkit.

But of course there could be some more advertising on the dlang 
page for the different ui toolkits.

Kind regards
Andre
Feb 10 2019
prev sibling parent Rubn <where is.this> writes:
On Sunday, 10 February 2019 at 10:22:07 UTC, Ecstatic Coder wrote:

 On Sunday, 10 February 2019 at 01:13:16 UTC, 0xEAB wrote:

 On Friday, 8 February 2019 at 12:09:20 UTC, Ecstatic Coder 
 wrote:

 And very honestly, preinstalling dlangui


 What qualifies DlangUI to become the default GUI lib that 
 should be pre-installed (in terms of: what disqualifies other 
 libs)?


  - Elias


 Just try them all, and you will quickly find which one is the 
 most cross-platform, compiles easily, runs fast on all the 
 platforms, behaves the same everywhere, can use 3D or canvas 
 rendering, has small dependencies, can be easily mixed with 3D 
 rendering too and gets the job done with crystal clear code.

 Gtkd, tkd, etc are all good, but as you guess my personal 
 favorite one is obviously dlangui, for all the reasons above...


It really depends on what you are doing, not everyone needs are 
going to met with one UI. I don't think a UI should be included 
with DMD, there's a reason very few languages do it. Especially 
ones that compile to machine code.


 behaves the same everywhere


That wouldn't be a plus for everyone. People expect their 
programs to behave a certain way
  for their platform. Not having the look and feel of their 
platform is enough for people to not like using it.

It's a 8 mb download, there's really no reason to preinstall or 
include it into the standard.
Feb 10 2019
prev sibling next sibling parent reply sai <sai dummy.com> writes:
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.
Feb 05 2019
parent Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:
On Tuesday, 5 February 2019 at 20:15:55 UTC, sai wrote:

 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.


On a Windows 10 VM I had lying around that should be bare, the 
following worked for me:
- Installing dmd for Windows from dlang.org
- Not installing anything from Visual Studio during dmd's 
installation
- Installing the Visual C++ runtimes 2010 and 2013 from 
microsoft.com 
(https://www.microsoft.com/download/details.aspx?id=14632 and 
https://www.microsoft.com/download/details.aspx?id=40784)
- In a command prompt, in whichever directory you'd like to work: 
`dub init --type=vibe.d hello-web`
- `cd hello-web`
- `dub run --arch=x86_64`

This seemed to be enough to have a Hello World on 127.0.0.1:8080, 
I hope I hadn't done anything else I've forgotten.
Feb 05 2019
prev sibling parent Rubn <where is.this> writes:
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 
:).
Feb 05 2019
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Saturday, 2 February 2019 at 02:32:28 UTC, Ben wrote:

 Not to be a downer but just trying out D again with Vibe.d and 
 getting confronted with the typical bug: Unexpected OPTLINK 
 Termination at EIP=0040F60A

 [...]


You can also set the default architecture to x86_64 for all dub 
projects as described here

https://dub.pm/settings.html

Kind regards
Andre
Feb 01 2019
next sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Saturday, 2 February 2019 at 06:23:32 UTC, Andre Pany wrote:


 You can also set the default architecture to x86_64 for all dub 
 projects as described here

 https://dub.pm/settings.html


Is this a typo:

%APPDATA%\dub\settings.json

Shouldn't it be:

%APPDATA%\roaming\dub\settings.json

or:

%APPDATA%\local\dub\settings.json

I've never seen any software create it's folder at the top level 
of %APPDATA%.
Feb 03 2019
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Sunday, 3 February 2019 at 10:20:41 UTC, Ron Tarrant wrote:

 On Saturday, 2 February 2019 at 06:23:32 UTC, Andre Pany wrote:


 You can also set the default architecture to x86_64 for all 
 dub projects as described here

 https://dub.pm/settings.html


 Is this a typo:

 %APPDATA%\dub\settings.json

 Shouldn't it be:

 %APPDATA%\roaming\dub\settings.json

 or:

 %APPDATA%\local\dub\settings.json

 I've never seen any software create it's folder at the top 
 level of %APPDATA%.


The environment variable APPDATA points to the roaming folder.

Kind regards
Andre
Feb 03 2019
parent reply Ron Tarrant <rontarrant gmail.com> writes:
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.
Feb 03 2019
parent bauss <jj_1337 live.dk> writes:
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!
Feb 03 2019
prev sibling parent Ron Tarrant <rontarrant gmail.com> writes:
On Saturday, 2 February 2019 at 06:23:32 UTC, Andre Pany wrote:


 You can also set the default architecture to x86_64 for all dub 
 projects as described here

 https://dub.pm/settings.html


But OTOH, creating a settings.json file in c:\ProgramData with 
the following contents:

{
	"defaultArchitecture": "x86_64",
	"defaultCompiler": "ldc"
}

has solved my dub linking problem. Perhaps creating this file 
could become part of the Windows install process, or at least, an 
option during installation.
Feb 03 2019
prev sibling parent reply bauss <jj_1337 live.dk> writes:
On Saturday, 2 February 2019 at 02:32:28 UTC, Ben wrote:

 Not to be a downer but just trying out D again with Vibe.d and 
 getting confronted with the typical bug: Unexpected OPTLINK 
 Termination at EIP=0040F60A

 Tracing this back, bring up issues in the bugtracker from 2017 
 ( 17508 ), that is still open.

 First impressions and such matter. And for some reason ever new 
 "first impression" with D seems to result in annoying bugs 
 being discovered ( Windows 10 ).

 Yes, i already know. No Visual Studio linker installed ( and 
 no, i do not want a 3GB installation just for the linker, when 
 DMD already includes it ). But somebody forgot to tell dub!

 So anybody using Vibe.d or any other project that rely on dub 
 figuring out that DMD can be run without Visual Studios linker, 
 can enjoy very nice and cryptic errors. User friendly it is not.

 /Frustrated that this is still a issue.


vibe.d doesn't compile with OPTLINK and it hasn't for years.

Just use the Microsoft linker by passing:

-a=x86_mscoff when building using dub.

Also look forward to the future when you don't need to install 
Visual Studio to get the linker as it will ship with DMD (If it 
doesn't already? It's been a while since I've checked.)
Feb 02 2019
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Saturday, 2 February 2019 at 12:11:56 UTC, bauss wrote:

 Also look forward to the future when you don't need to install 
 Visual Studio to get the linker as it will ship with DMD (If it 
 doesn't already? It's been a while since I've checked.)


It is. But there is another problem. D is a SYSTEM programming 
language, not just some productivity language. It means there is 
still dependency on the system libs! Heck, even Rust given up 
with jemalloc in favor of system allocator by default, if this 
says something...
Of course the problem with packaging the libs with compiler 
installation can be solved by using same approach MinGW did, like 
people say, or even using the MinGW libs if it is possible.
Feb 02 2019
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Saturday, 2 February 2019 at 13:18:08 UTC, evilrat wrote:

 On Saturday, 2 February 2019 at 12:11:56 UTC, bauss wrote:

 Also look forward to the future when you don't need to install 
 Visual Studio to get the linker as it will ship with DMD (If 
 it doesn't already? It's been a while since I've checked.)


 It is. But there is another problem. D is a SYSTEM programming 
 language, not just some productivity language. It means there 
 is still dependency on the system libs! Heck, even Rust given 
 up with jemalloc in favor of system allocator by default, if 
 this says something...
 Of course the problem with packaging the libs with compiler 
 installation can be solved by using same approach MinGW did, 
 like people say, or even using the MinGW libs if it is possible.


Mingw libs and headers are also included in recent dmd. Except of 
rare cases you may not need anymore to install vs or build tools.

Kind regards
Andre
Feb 02 2019
parent reply Rubn <where is.this> writes:
On Saturday, 2 February 2019 at 14:36:00 UTC, Andre Pany wrote:

 On Saturday, 2 February 2019 at 13:18:08 UTC, evilrat wrote:

 On Saturday, 2 February 2019 at 12:11:56 UTC, bauss wrote:

 Also look forward to the future when you don't need to 
 install Visual Studio to get the linker as it will ship with 
 DMD (If it doesn't already? It's been a while since I've 
 checked.)


 It is. But there is another problem. D is a SYSTEM programming 
 language, not just some productivity language. It means there 
 is still dependency on the system libs! Heck, even Rust given 
 up with jemalloc in favor of system allocator by default, if 
 this says something...
 Of course the problem with packaging the libs with compiler 
 installation can be solved by using same approach MinGW did, 
 like people say, or even using the MinGW libs if it is 
 possible.


 Mingw libs and headers are also included in recent dmd. Except 
 of rare cases you may not need anymore to install vs or build 
 tools.

 Kind regards
 Andre


I don't get people complaining about and they are usually 
misinformed as well. You can install VC++ for 1.5 GB using the 
Build Tool install. Of that 1.5 GB 1 GB are library files and 
most of that is for the static libraries for the runtime. The 
last time this came up someone was developing on a cheap tablet 
or something with 16 GB of space that isn't expandable.
Feb 02 2019
next sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Saturday, 2 February 2019 at 15:43:56 UTC, Rubn wrote:

 On Saturday, 2 February 2019 at 14:36:00 UTC, Andre Pany wrote:

 On Saturday, 2 February 2019 at 13:18:08 UTC, evilrat wrote:

 On Saturday, 2 February 2019 at 12:11:56 UTC, bauss wrote:

 [...]


 It is. But there is another problem. D is a SYSTEM 
 programming language, not just some productivity language. It 
 means there is still dependency on the system libs! Heck, 
 even Rust given up with jemalloc in favor of system allocator 
 by default, if this says something...
 Of course the problem with packaging the libs with compiler 
 installation can be solved by using same approach MinGW did, 
 like people say, or even using the MinGW libs if it is 
 possible.


 Mingw libs and headers are also included in recent dmd. Except 
 of rare cases you may not need anymore to install vs or build 
 tools.

 Kind regards
 Andre


 I don't get people complaining about and they are usually 
 misinformed as well. You can install VC++ for 1.5 GB using the 
 Build Tool install. Of that 1.5 GB 1 GB are library files and 
 most of that is for the static libraries for the runtime. The 
 last time this came up someone was developing on a cheap tablet 
 or something with 16 GB of space that isn't expandable.


I completely agree. On the other side, due to the hard work of 
some fantastic people, today you can just extract the dmd zip and 
immediately compile 64 bit applications on windows. This user 
experience will attract  a lot of new users.

Kind regards
Andre
Feb 02 2019
prev sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Saturday, 2 February 2019 at 15:43:56 UTC, Rubn wrote:

 On Saturday, 2 February 2019 at 14:36:00 UTC, Andre Pany wrote:

 On Saturday, 2 February 2019 at 13:18:08 UTC, evilrat wrote:

 On Saturday, 2 February 2019 at 12:11:56 UTC, bauss wrote:

 Also look forward to the future when you don't need to 
 install Visual Studio to get the linker as it will ship with 
 DMD (If it doesn't already? It's been a while since I've 
 checked.)


 It is. But there is another problem. D is a SYSTEM 
 programming language, not just some productivity language. It 
 means there is still dependency on the system libs! Heck, 
 even Rust given up with jemalloc in favor of system allocator 
 by default, if this says something...
 Of course the problem with packaging the libs with compiler 
 installation can be solved by using same approach MinGW did, 
 like people say, or even using the MinGW libs if it is 
 possible.


 Mingw libs and headers are also included in recent dmd. Except 
 of rare cases you may not need anymore to install vs or build 
 tools.

 Kind regards
 Andre


 I don't get people complaining about and they are usually 
 misinformed as well. You can install VC++ for 1.5 GB using the 
 Build Tool install. Of that 1.5 GB 1 GB are library files and 
 most of that is for the static libraries for the runtime. The 
 last time this came up someone was developing on a cheap tablet 
 or something with 16 GB of space that isn't expandable.


I think that the reason why people complain is that not everybody 
thinks in the same way as you.

Seriously, the last time I had to install D on my freshly 
reinstalled Windows partition, I almost gave up before finishing 
the installation procedure, because it once seemed I was doomed 
to unavoidingly install the X GB of Visual Studio environment (or 
its build tools, same problem) just to install a small D compiler 
needed to build my tiny single-file tools (Basil, Pendown, etc) 
on Windows.

By luck, I tried the Mingw option, which worked and this saved my 
day, but I think you have no idea how unlikely people will click 
on this Mingw option, and how this little install menu design can 
turn off people from D if they were just trying to experiment it 
as a Python or Ruby alternative, because **not everyone** is 
willing to start that LONG and HUGE Visual Studio thing just to 
try the finally-not-so-swift D compiler which seems to need it.

IMO, the two most urgent things you should improve to avoid 
immediately pushing people away from their curiosity about D is :

1/ make D's web site landing page show D advantages from the user 
point of view : why D would be better than Python etc to make 
file processing scripts, GUI applications, web servers, etc
2/ make the installation process quick and easy : you download a 
<50MB installer executable, click install, and in less than 2 
minutes you are ready to go.

For 1, you should really consider putting this text on the 
landing page :

"D is a powerful and expressive language which compiles directly 
to efficient, native machine code.

It is the culmination of decades of experience implementing 
compilers for many diverse languages and has a unique set of 
features:

     high level constructs for great modeling power
     high performance, compiled language
     static typing
     direct interface to the operating system API's and hardware
     blazingly fast compile-times
     memory-safe subset (SafeD)
     maintainable, easy to understand code
     gradual learning curve (C-like syntax, similar to Java and 
others)
     compatible with C application binary interface
     limited compatibility with C++ application binary interface
     multi-paradigm (imperative, structured, object oriented, 
generic, functional programming purity, and even assembly)
     built-in error detection (contracts, unittests)"

Followed by THREE examples :

1. a very simple one which shows D basic syntax "a la 
JavaScript", by showing how to declare an string array, 
initialize it with [ "apple", "banana", "orange" ], how to 
iterate on them, print them, etc

2. a small "hello world" web server example (the one using vibe.d 
you see IF you select that example)

3. a small GUI example (opening a window with a menu, two radio 
buttons and a scroll view, using dlangui)

All directly visible, with a small text explaining how it is easy 
to :
1. make JavaScript/Python/Ruby like file scripting
2. easily develop web servers with vibe.d
3. easily develop multiplatform (Win/Mac/Linux) desktop with 
dlangui (which rocks btw)

And for the second point, about the installer, put the quick & 
easy installation option (Mingw) above and selected by default.

Or completely ignore those advices, and be happy what you think 
is already perfect for D's newcomers :)
Feb 02 2019
next sibling parent Rubn <where is.this> writes:
On Saturday, 2 February 2019 at 16:43:34 UTC, Ecstatic Coder 
wrote:

 On Saturday, 2 February 2019 at 15:43:56 UTC, Rubn wrote:

 On Saturday, 2 February 2019 at 14:36:00 UTC, Andre Pany wrote:

 On Saturday, 2 February 2019 at 13:18:08 UTC, evilrat wrote:

 On Saturday, 2 February 2019 at 12:11:56 UTC, bauss wrote:

 Also look forward to the future when you don't need to 
 install Visual Studio to get the linker as it will ship 
 with DMD (If it doesn't already? It's been a while since 
 I've checked.)


 It is. But there is another problem. D is a SYSTEM 
 programming language, not just some productivity language. 
 It means there is still dependency on the system libs! Heck, 
 even Rust given up with jemalloc in favor of system 
 allocator by default, if this says something...
 Of course the problem with packaging the libs with compiler 
 installation can be solved by using same approach MinGW did, 
 like people say, or even using the MinGW libs if it is 
 possible.


 Mingw libs and headers are also included in recent dmd. 
 Except of rare cases you may not need anymore to install vs 
 or build tools.

 Kind regards
 Andre


 I don't get people complaining about and they are usually 
 misinformed as well. You can install VC++ for 1.5 GB using the 
 Build Tool install. Of that 1.5 GB 1 GB are library files and 
 most of that is for the static libraries for the runtime. The 
 last time this came up someone was developing on a cheap 
 tablet or something with 16 GB of space that isn't expandable.


 I think that the reason why people complain is that not 
 everybody thinks in the same way as you.


Never said otherwise, I can have my own opinion and people can 
have theirs and I can have the opinion that their opinions are 
silly.


 Seriously, the last time I had to install D on my freshly 
 reinstalled Windows partition, I almost gave up before 
 finishing the installation procedure, because it once seemed I 
 was doomed to unavoidingly install the X GB of Visual Studio 
 environment (or its build tools, same problem) just to install 
 a small D compiler needed to build my tiny single-file tools 
 (Basil, Pendown, etc) on Windows.


Well at least you said "X GB" instead of just fabricating an 
incorrect number like everyone else :). And how did you get that 
small compiler to work in the first place? I guess you've never 
had to install your Windows operating system. I can only imagine 
you complaining about having to install a 20 GB operating system 
just to be able to install a small D compiler to build a tiny 
single-file tool. The D compiler can be small and your tool and 
be tiny because the complexity of what is actually going on is 
hidden from you, you don't have to worry about it. But alas 
people still complain with horrible metaphors.


 By luck, I tried the Mingw option, which worked and this saved 
 my day, but I think you have no idea how unlikely people will 
 click on this Mingw option, and how this little install menu 
 design can turn off people from D if they were just trying to 
 experiment it as a Python or Ruby alternative, because **not 
 everyone** is willing to start that LONG and HUGE Visual Studio 
 thing just to try the finally-not-so-swift D compiler which 
 seems to need it.


Lol, I can't help but laugh "long" and "huge" visual studio 
thing. As I sit here downloading a 40 GB file, you have no idea 
the meaning of long or huge. What you need are the VC++ runtime 
libraries and the linker. Visual Studio is an IDE, they are two 
different projects and you don't need the IDE to compile and link 
programs on Windows.

There's your problem, you are comparing D, a language that 
compiles to native machine code with interpreted languages that 
are specifically designed to be overly simplistic and go to great 
lengths to hide operating system and architecture specific 
problems. Hardly a fair comparison and D will probably never be 
as simple to use as those, as you don't need any development 
system libraries to use those languages. That's the benefit of an 
interpreted language.


 IMO, the two most urgent things you should improve to avoid 
 immediately pushing people away from their curiosity about D is 
 :

 1/ make D's web site landing page show D advantages from the 
 user point of view : why D would be better than Python etc to 
 make file processing scripts, GUI applications, web servers, etc


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

https://dlang.org/

"Start a minimal web server"


/+ dub.sdl:
name "hello_vibed"
dependency "vibe-d" version="~>0.8.0"
+/
void main()
{
     import vibe.d;
     listenHTTP(":8080", (req, res) {
         res.writeBody("Hello, World: " ~ req.path);
     });
     runApplication();
}



 2/ make the installation process quick and easy : you download 
 a <50MB installer executable, click install, and in less than 2 
 minutes you are ready to go.

 For 1, you should really consider putting this text on the 
 landing page :

 "D is a powerful and expressive language which compiles 
 directly to efficient, native machine code.

 It is the culmination of decades of experience implementing 
 compilers for many diverse languages and has a unique set of 
 features:

     high level constructs for great modeling power
     high performance, compiled language
     static typing
     direct interface to the operating system API's and hardware
     blazingly fast compile-times
     memory-safe subset (SafeD)
     maintainable, easy to understand code
     gradual learning curve (C-like syntax, similar to Java and 
 others)
     compatible with C application binary interface
     limited compatibility with C++ application binary interface
     multi-paradigm (imperative, structured, object oriented, 
 generic, functional programming purity, and even assembly)
     built-in error detection (contracts, unittests)"

 Followed by THREE examples :

 1. a very simple one which shows D basic syntax "a la 
 JavaScript", by showing how to declare an string array, 
 initialize it with [ "apple", "banana", "orange" ], how to 
 iterate on them, print them, etc

 2. a small "hello world" web server example (the one using 
 vibe.d you see IF you select that example)

 3. a small GUI example (opening a window with a menu, two radio 
 buttons and a scroll view, using dlangui)

 All directly visible, with a small text explaining how it is 
 easy to :
 1. make JavaScript/Python/Ruby like file scripting
 2. easily develop web servers with vibe.d
 3. easily develop multiplatform (Win/Mac/Linux) desktop with 
 dlangui (which rocks btw)

 And for the second point, about the installer, put the quick & 
 easy installation option (Mingw) above and selected by default.

 Or completely ignore those advices, and be happy what you think 
 is already perfect for D's newcomers :)


It's not really my decision and I never said anything was good 
about what D is already doing. It needs to chuck that optlink 
linker garbage into the bin where it belongs.
Feb 02 2019
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Saturday, 2 February 2019 at 16:43:34 UTC, Ecstatic Coder 
wrote:

 On Saturday, 2 February 2019 at 15:43:56 UTC, Rubn wrote:

 [...]


 I think that the reason why people complain is that not 
 everybody thinks in the same way as you.

 [...]


DMD64 could be released for windows now, with -m64 the default 
just like under linux or osx. This would work. Actually people 
still download the 32 bit compiler after all so this is not so 
crazy that it defaults to -m32
Feb 02 2019
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Saturday, 2 February 2019 at 20:50:58 UTC, Basile B. wrote:

 On Saturday, 2 February 2019 at 16:43:34 UTC, Ecstatic Coder 
 wrote:

 On Saturday, 2 February 2019 at 15:43:56 UTC, Rubn wrote:

 [...]


 I think that the reason why people complain is that not 
 everybody thinks in the same way as you.

 [...]


 DMD64 could be released for windows now, with -m64 the default 
 just like under linux or osx. This would work. Actually people 
 still download the 32 bit compiler after all so this is not so 
 crazy that it defaults to -m32


For DMD to be a truly multi-platform language 
(Windows/Linux/MacOS), consistency across platforms should always 
be a must, never an option.

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.

And I've experienced this problem first hand...

D is clearly what I call an "almost" cross-platform language.

It could be close to perfection on that aspect, but unfortunately 
a few poor decisions here and there regularly breaks its 
cross-platform behavior in a very annoying way.
Feb 03 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
Feb 03 2019
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
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)
Feb 03 2019
next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
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)


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
Feb 03 2019
next sibling parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
 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...
Feb 03 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2019 3:41 AM, Andre Pany wrote:

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


Compiling 64 bit executables on Windows relies on the user having the Microsoft 
VS tools installed. For 32 bit executables, we ship everything needed.
Feb 10 2019
parent Seb <seb wilzba.ch> writes:
On Sunday, 10 February 2019 at 23:11:17 UTC, Walter Bright wrote:

 On 2/3/2019 3:41 AM, Andre Pany wrote:

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


 Compiling 64 bit executables on Windows relies on the user 
 having the Microsoft VS tools installed. For 32 bit 
 executables, we ship everything needed.


Thanks to Reiner's excellent work this isn't true anymore since 
already a year (2.079):

https://dlang.org/changelog/2.079.0.html#lld_mingw
Feb 10 2019
prev sibling parent reply Rubn <where is.this> writes:
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.
Feb 03 2019
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
 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
Feb 03 2019
parent Basile B. <b2.temp gmx.com> writes:
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 ?
Feb 03 2019
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2019-02-02 13:11, bauss wrote:


 Also look forward to the future when you don't need to install Visual 
 Studio to get the linker as it will ship with DMD (If it doesn't 
 already? It's been a while since I've checked.)


The linker is already shipped with DMD.

-- 
/Jacob Carlborg
Feb 02 2019