www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Breaking changes in Visual C++ 2015

reply "Brad Anderson" <eco gnuk.net> writes:
https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx

I'm sharing this specifically so we can have an unproductive 
flamewar about whether breaking changes in D are sometimes worth 
it or if they are holding D back from mass adoption :).
May 06 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 6 May 2015 at 18:26:27 UTC, Brad Anderson wrote:

 https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx

 I'm sharing this specifically so we can have an unproductive 
 flamewar about whether breaking changes in D are sometimes 
 worth it or if they are holding D back from mass adoption :).


How about a productive design oriented working group instead of a 
flame war?

I totally side with Walter when he says that drip-drip-drip 
changes are taxing on people who does not work full time with a 
language, but have serious intents with being involved.

I also totally understand his fear of alienating the existing 
user base by changing the language in ways that makes the 
existing user base change their personal programming idioms 
(whether they are sound and clean or the opposite).

However, rhe transition to D for DMD provides:

- Opportunity to rethink compiler internals.

- Opportunity to refactor the compiler so that you can get better 
tooling/automatic transcompiling from D2 to a hypthetical D3 if 
need be.

And therefore also an opportunity to rethink the language 
semantics.

If you want to rethink language semantics you should start with 
tabula rasa (assume no existing langauge). Then come up with the 
hypothetical ideal high level design for the kind of programming 
D is meant for. When you have that, you have much better chance 
to redesign the existing language with an upgrade path to 
something consistent.

Semantic drip-drip-drip metamorphosis is generally not very good 
for an axiomatic system (which programming language internals 
have to be).

If it was up to me I'd focus on 5 areas:

- stronger typing / behavioural typing

- memory model

- see if it is possible to redesign and implement the templating 
system with something that is close to Datalog to get  more 
streamlined metaprogramming

- high level IR for whole program optimization with partial 
evaluation

- identifying a sub langauge that can be used for building a 
small SIMD oriented backend for innnerloops (generating different 
variants SSE2/SSE3/AVX/AVX2 based on cpu info).
May 07 2015
prev sibling next sibling parent reply "d user" <dddddddddd dd.com> writes:
On Wednesday, 6 May 2015 at 18:26:27 UTC, Brad Anderson wrote:

 https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx

 I'm sharing this specifically so we can have an unproductive 
 flamewar about whether breaking changes in D are sometimes 
 worth it or if they are holding D back from mass adoption :).


the truth is, one of the biggest things holding D back from mass 
adoption is the complete lack of tooling compared to  basically 
every other mainstream language.

Compare D to Go,
https://golang.org/cmd/go/

Go comes with a package manager, a linter, a static analysis 
tool, a formatter. Does D have these in some form? Sure. But you 
have to go hunting for them, and they're OK at best.

And really, the only thing to blame for this is dmd. Go provides 
a Go parser and tokenizer right in their standard library - just 
one of the benefits of their compiler being written in Go.

A lot of D's issues come back to: dmd is long in the tooth. 
Things D used to tout(faster compiler times) aren't really there 
anymore. My _desktop_ has a 8 core CPU - which dmd uses a whole 1 
of when compiling. Due to how modules are compiled, it's _slower_ 
to do separate object compilation like in C++, so it's impossible 
to even get a gain from parallel compilation.

Then you have LDC and GDC which generally lag behind dmd by a 
version or two(usually moreso for GDC,) fragmenting the libraries 
heavily because many new D versions fix tons of bugs. Due to 
dmd's license, it can't even be redistributed on Linux, BSD, etc. 
So now you have compilers for major Linux distros that are 
lagging versions behind. And really, the packages aren't well 
maintained anyways - LDC got blacklisted from Ubuntu for being 
unmaintained.

If there's anything to learn from Go's success, it's that you 
don't need a good language design to be successful. If you want D 
to be successful, submit some PRs to SDC. If you want D to stay 
unpopular, keep moving towards Haskell with braces.
May 07 2015
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 7 May 2015 at 14:16, d user via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 6 May 2015 at 18:26:27 UTC, Brad Anderson wrote:

 https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx

 I'm sharing this specifically so we can have an unproductive flamewar
 about whether breaking changes in D are sometimes worth it or if they are
 holding D back from mass adoption :).



 the truth is, one of the biggest things holding D back from mass adoption is
 the complete lack of tooling compared to  basically every other mainstream
 language.

 Compare D to Go,
 https://golang.org/cmd/go/

 Go comes with a package manager, a linter, a static analysis tool, a
 formatter. Does D have these in some form? Sure. But you have to go hunting
 for them, and they're OK at best.

 And really, the only thing to blame for this is dmd. Go provides a Go parser
 and tokenizer right in their standard library - just one of the benefits of
 their compiler being written in Go.

 A lot of D's issues come back to: dmd is long in the tooth. Things D used to
 tout(faster compiler times) aren't really there anymore. My _desktop_ has a
 8 core CPU - which dmd uses a whole 1 of when compiling. Due to how modules
 are compiled, it's _slower_ to do separate object compilation like in C++,
 so it's impossible to even get a gain from parallel compilation.

 Then you have LDC and GDC which generally lag behind dmd by a version or
 two(usually moreso for GDC,) fragmenting the libraries heavily because many


*Ahem* don't make such wild claims without backing with recent and
relevant evidence.



 new D versions fix tons of bugs. Due to dmd's license, it can't even be
 redistributed on Linux, BSD, etc. So now you have compilers for major Linux
 distros that are lagging versions behind. And really, the packages aren't
 well maintained anyways - LDC got blacklisted from Ubuntu for being
 unmaintained.


There's a difference between blacklisted and dropped.  In any case, it
has a new maintainer and is back in now...
May 07 2015
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 7 May 2015 at 12:16:18 UTC, d user wrote:

 If there's anything to learn from Go's success, it's that you 
 don't need a good language design to be successful. If you want 
 D to be successful, submit some PRs to SDC. If you want D to 
 stay unpopular, keep moving towards Haskell with braces.


I think Go's "success" comes from:

1. C++14 is too complicated to make sense for many commercial 
projects.

2. Java et al are heavy weight and makes little sense for 
small-and-easy-to-deploy projects.

3. Go is designed around a single concurrency idiom with 
theoretical backing, which makes running a pilot with it 
motivating.

4. Corporate backing.

5. It takes a stance on aesthetics and is therefore not too 
difficult to master.


I'd like to see someone make a list of programming languages that 
are consistently growing (I think popularity is the wrong metric, 
it can take decades). I bet they either:

1. focus on a particular sense of aesthetics

2. are tied to a framework

3. are domain specific

Very few languages ship with extensive tooling from the start. 
Tooling gives a boost, but as you can see with Dart, that is not 
sufficient. And Dart is arguably a better language than Go with 
strong domain specific advantages...
May 07 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/7/15 5:16 AM, d user wrote:

 On Wednesday, 6 May 2015 at 18:26:27 UTC, Brad Anderson wrote:

 https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx

 I'm sharing this specifically so we can have an unproductive flamewar
 about whether breaking changes in D are sometimes worth it or if they
 are holding D back from mass adoption :).


 the truth is, one of the biggest things holding D back from mass
 adoption is the complete lack of tooling compared to  basically every
 other mainstream language.

 Compare D to Go,
 https://golang.org/cmd/go/

 Go comes with a package manager, a linter, a static analysis tool, a
 formatter. Does D have these in some form? Sure. But you have to go
 hunting for them, and they're OK at best.

 And really, the only thing to blame for this is dmd. Go provides a Go
 parser and tokenizer right in their standard library - just one of the
 benefits of their compiler being written in Go.

 A lot of D's issues come back to: dmd is long in the tooth. Things D
 used to tout(faster compiler times) aren't really there anymore. My
 _desktop_ has a 8 core CPU - which dmd uses a whole 1 of when compiling.
 Due to how modules are compiled, it's _slower_ to do separate object
 compilation like in C++, so it's impossible to even get a gain from
 parallel compilation.

 Then you have LDC and GDC which generally lag behind dmd by a version or
 two(usually moreso for GDC,) fragmenting the libraries heavily because
 many new D versions fix tons of bugs. Due to dmd's license, it can't
 even be redistributed on Linux, BSD, etc. So now you have compilers for
 major Linux distros that are lagging versions behind. And really, the
 packages aren't well maintained anyways - LDC got blacklisted from
 Ubuntu for being unmaintained.

 If there's anything to learn from Go's success, it's that you don't need
 a good language design to be successful. If you want D to be successful,
 submit some PRs to SDC. If you want D to stay unpopular, keep moving
 towards Haskell with braces.


Agreed except for one point - compilation speed. I've very carefully 
measured on comparable projects. Go is marginally faster to compile than 
dmd, but dmd is faster than Rust. C++ can't hold a candle to either 
without a large specialized build farm and a team to babysit it. -- Andrei
May 07 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/7/15 7:41 AM, Andrei Alexandrescu wrote:

 On 5/7/15 5:16 AM, d user wrote:

 On Wednesday, 6 May 2015 at 18:26:27 UTC, Brad Anderson wrote:

 https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx

 I'm sharing this specifically so we can have an unproductive flamewar
 about whether breaking changes in D are sometimes worth it or if they
 are holding D back from mass adoption :).


 the truth is, one of the biggest things holding D back from mass
 adoption is the complete lack of tooling compared to  basically every
 other mainstream language.

 Compare D to Go,
 https://golang.org/cmd/go/

 Go comes with a package manager, a linter, a static analysis tool, a
 formatter. Does D have these in some form? Sure. But you have to go
 hunting for them, and they're OK at best.

 And really, the only thing to blame for this is dmd. Go provides a Go
 parser and tokenizer right in their standard library - just one of the
 benefits of their compiler being written in Go.

 A lot of D's issues come back to: dmd is long in the tooth. Things D
 used to tout(faster compiler times) aren't really there anymore. My
 _desktop_ has a 8 core CPU - which dmd uses a whole 1 of when compiling.
 Due to how modules are compiled, it's _slower_ to do separate object
 compilation like in C++, so it's impossible to even get a gain from
 parallel compilation.

 Then you have LDC and GDC which generally lag behind dmd by a version or
 two(usually moreso for GDC,) fragmenting the libraries heavily because
 many new D versions fix tons of bugs. Due to dmd's license, it can't
 even be redistributed on Linux, BSD, etc. So now you have compilers for
 major Linux distros that are lagging versions behind. And really, the
 packages aren't well maintained anyways - LDC got blacklisted from
 Ubuntu for being unmaintained.

 If there's anything to learn from Go's success, it's that you don't need
 a good language design to be successful. If you want D to be successful,
 submit some PRs to SDC. If you want D to stay unpopular, keep moving
 towards Haskell with braces.


 Agreed except for one point - compilation speed. I've very carefully
 measured on comparable projects. Go is marginally faster to compile than
 dmd, but dmd is faster than Rust. C++ can't hold a candle to either
 without a large specialized build farm and a team to babysit it. -- Andrei


Ah, and the bleak outlook of LDC and GDC. -- Andrei
May 07 2015
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 07 May 2015 12:16:17 +0000, d user wrote:


 If you want D to stay unpopular, keep moving
 towards Haskell with braces.


i'll go with "Haskell with braces".=
May 07 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/7/2015 5:16 AM, d user wrote:

 the truth is, one of the biggest things holding D back from mass adoption is
the
 complete lack of tooling compared to  basically every other mainstream
language.


D has some excellent tools that are generally nonstandard, klunky or
nonexistent 
in other languages:

1. unit testing
2. documentation generation
3. coverage analysis
4. profiler
5. and as of last week, a memory usage profiler

I know many feel that these features can be improved, sure. But the first three 
have knocked the ball out of the park, and number four is a solid hit. And 
frankly, if I had to choose between 1..5 and package manager, static analysis 
tool, linter, and formatter, I'd choose the former.

That said, I hope to integrate dfmt in with the main distribution soon. And we 
are going to switch dmd front end to D in the near future.

But let's not forget the meat and potatoes on our plate while looking at our 
neighbor's salad dressing.
May 07 2015
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-05-08 00:28, Walter Bright wrote:


 D has some excellent tools that are generally nonstandard, klunky or
 nonexistent in other languages:

 1. unit testing
 2. documentation generation
 3. coverage analysis
 4. profiler
 5. and as of last week, a memory usage profiler

 I know many feel that these features can be improved, sure. But the
 first three have knocked the ball out of the park, and number four is a
 solid hit. And frankly, if I had to choose between 1..5 and package
 manager, static analysis tool, linter, and formatter, I'd choose the
 former.


I guess we just have different preferences. I would only choose unit 
testing and documentation generation from your list, if I have to 
choose. Perhaps I would even choose package manager as the most 
important tool, because the other tools could be provided by packages in 
the package manager.

Regards to unit testing, if I compare that with Ruby, for example. Ruby 
doesn't have language support for unit tests but there are two major 
unit test libraries in use, one which is included in the standard library.

The built-in unit testing in D is so limiting that a third party 
framework is needed anyway, and here there's no obvious library to pick.

-- 
/Jacob Carlborg
May 07 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/7/2015 11:30 PM, Jacob Carlborg wrote:

 On 2015-05-08 00:28, Walter Bright wrote:


 D has some excellent tools that are generally nonstandard, klunky or
 nonexistent in other languages:

 1. unit testing
 2. documentation generation
 3. coverage analysis
 4. profiler
 5. and as of last week, a memory usage profiler

 I know many feel that these features can be improved, sure. But the
 first three have knocked the ball out of the park, and number four is a
 solid hit. And frankly, if I had to choose between 1..5 and package
 manager, static analysis tool, linter, and formatter, I'd choose the
 former.


 I guess we just have different preferences. I would only choose unit testing
and
 documentation generation from your list, if I have to choose. Perhaps I would
 even choose package manager as the most important tool, because the other tools
 could be provided by packages in the package manager.


The coverage analysis is necessary to make the unit testing effective. 
Otherwise, one is just shooting in the dark. My experience developing Warp was 
typical - I went back and forth between unit tests and coverage analysis from 
the ground up. The result was Warp was developed unusually quickly and had
very, 
very few bugs show up after release.


You don't have to add another package, run other tools, etc., like in other 
languages. Just throw a switch. This convenience should not be underestimated.

One big reason I want dmd to be in D is to get the unit testing.



 Regards to unit testing, if I compare that with Ruby, for example. Ruby doesn't
 have language support for unit tests but there are two major unit test
libraries
 in use, one which is included in the standard library.

 The built-in unit testing in D is so limiting that a third party framework is
 needed anyway, and here there's no obvious library to pick.


On the other hand, D's builtin unit testing is so effective it has been a game 
changer, in that it has successfully changed the culture of D programming.
May 08 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-05-08 09:55, Walter Bright wrote:


 On the other hand, D's builtin unit testing is so effective it has been
 a game changer, in that it has successfully changed the culture of D
 programming.


Perhaps compared to C++ or previous D code. But compared to Ruby it's 
certainly not a game changer and has a long way to go.

-- 
/Jacob Carlborg
May 08 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/8/2015 1:33 AM, Jacob Carlborg wrote:

 On 2015-05-08 09:55, Walter Bright wrote:


 On the other hand, D's builtin unit testing is so effective it has been
 a game changer, in that it has successfully changed the culture of D
 programming.


 Perhaps compared to C++ or previous D code. But compared to Ruby it's certainly
 not a game changer and has a long way to go.


I've never seen any as easy to use as D's, and that includes Ruby. Easy to use 
is what makes it a game changer, because people are much more likely to use it.

I know from long experience that when a test framework comes with a manual, 
people tend to not use it. It's just the way people are. If it's not builtin, 
people also tend not to use it.

I'm not claiming D has invented unit testing, nor that it is sophisticated. But 
it is trivial to use, and getting people to actually use it is what matters. 
It's like exercise - just getting out and doing something, anything, regularly 
is 90% of it.

It doesn't matter how sophisticated a testing and coverage tool is if people 
aren't using it as a matter of course. I've seen enough tool manuals sitting on 
programmers' shelves for years still in their shrink wrap.

For example, a well-known Ruby project, Rails. Picking a file pretty much at
random:

https://github.com/rails/rails/blob/master/actionmailer/lib/action_mailer/base.rb

No unit tests in it. Poking around, I found this:

https://github.com/rails/rails/blob/master/actionmailer/test/base_test.rb

in another directory. I presume those are the tests for base.rb. Why can't the 
tests be in base.rb? I assume there is some 3rd file that connects the two. I 
really like having the unit tests adjacent to the function under test, for the 
same reason that the Ddoc is adjacent. It sounds trite, but having them all 
together and not in some other file hierarchy is a game changer. It certainly 
changed things in D (before Ddoc, Phobos documentation was an utter disaster).

DMD has a set of source files in one directory, and test files in another. 
There's no obvious correspondence between code and its corresponding test. We 
don't actually know how good the test coverage is. I'm very much looking
forward 
to ddmd in order to address this. I expect this will result in a large increase 
in quality.
May 08 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-05-08 12:43, Walter Bright wrote:


 I've never seen any as easy to use as D's, and that includes Ruby. Easy
 to use is what makes it a game changer, because people are much more
 likely to use it.


As I've said, it's available in Ruby standard library, but perhaps 
that's not enough built-in for you.

Here's a simple Ruby unit test:

require 'minitest/autorun'

class TestMeme < MiniTest::Unit::TestCase
   def test_foo
     assert 1 == 1
   end
end

Run with "ruby foo.rb"

The D version:

module foo;

unittest
{
     assert(1 == 1);
}

Run with "dmd -main -unittest -run foo.d"

The Ruby version is slightly more complicated to type but easier to run. 
It's the opposite with D. The Ruby version will give you, out of the box:

* A nice report
* A bunch of assertions
* Setup and tear down methods
* Runs all tests even if a previous one failed

And some other stuff as well.


 I know from long experience that when a test framework comes with a
 manual, people tend to not use it. It's just the way people are. If it's
 not builtin, people also tend not to use it.

 I'm not claiming D has invented unit testing, nor that it is
 sophisticated. But it is trivial to use, and getting people to actually
 use it is what matters. It's like exercise - just getting out and doing
 something, anything, regularly is 90% of it.

 It doesn't matter how sophisticated a testing and coverage tool is if
 people aren't using it as a matter of course. I've seen enough tool
 manuals sitting on programmers' shelves for years still in their shrink
 wrap.

 For example, a well-known Ruby project, Rails. Picking a file pretty
 much at random:

 https://github.com/rails/rails/blob/master/actionmailer/lib/action_mailer/base.rb


 No unit tests in it. Poking around, I found this:

 https://github.com/rails/rails/blob/master/actionmailer/test/base_test.rb

 in another directory. I presume those are the tests for base.rb.


Yes.


 Why can't the tests be in base.rb?


It's the convention used in Ruby. It's perfectly possible to put the 
unit tests in the same file as the implementation, there's no technical 
limitation.

What do you do in D when it comes to integration and functional tests 
that test functionality across several modules?

In Ruby the convention is already to put the tests in the "test" 
directory so there's no special considerations in Ruby.


 I assume there is some 3rd file that connects the two.


Rails uses something called auto loading. If it can't find a class it 
will automatically try to require a file based on a convention. For 
plain Ruby you would just require whatever you want to test, as you 
would do in D, if you used a separate module.


 I really like having the unit tests adjacent to the
 function under test, for the same reason that the Ddoc is adjacent. It
 sounds trite, but having them all together and not in some other file
 hierarchy is a game changer. It certainly changed things in D (before
 Ddoc, Phobos documentation was an utter disaster).


I never liked to have the tests in the same file as the implementation. 
There's also all other kinds of tests that doesn't have a obvious 
implementation module to put them in. But Phobos doesn't have those kind 
of tests so the problem is avoided.


 DMD has a set of source files in one directory, and test files in
 another. There's no obvious correspondence between code and its
 corresponding test.


No, not the way those tests are written. But those are not unit tests, 
they're full stack tests.


 We don't actually know how good the test coverage
 is. I'm very much looking forward to ddmd in order to address this. I
 expect this will result in a large increase in quality.



-- 
/Jacob Carlborg
May 08 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
Thanks for the explanation.
May 08 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 7 May 2015 at 22:27:57 UTC, Walter Bright wrote:

 On 5/7/2015 5:16 AM, d user wrote:

 the truth is, one of the biggest things holding D back from 
 mass adoption is the
 complete lack of tooling compared to  basically every other 
 mainstream language.


 D has some excellent tools that are generally nonstandard, 
 klunky or nonexistent in other languages:

 1. unit testing
 2. documentation generation
 3. coverage analysis
 4. profiler
 5. and as of last week, a memory usage profiler


some of these really are klunky though.
e.g, if D's built-in unit testing is so good, why are there eight 
packages for unit testing on dub?
May 08 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/8/2015 12:45 AM, weaselcat wrote:

 some of these really are klunky though.


Nobody's ever satisfied. Doesn't mean the tools aren't effective, and doesn't 
mean a "complete lack of tooling".

I find:

    dmd std/algorithm -main -unittest -cov

quite far removed from 'klunky'. How do you do it in [pick a language]?



 e.g, if D's built-in unit testing is so good, why are there eight packages for
 unit testing on dub?


I haven't used them, and so have no opinion on them. I use the builtin 
capability every day I am working on D code, and find it easy and indispensable.
May 08 2015
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 8 May 2015 at 08:51:24 UTC, Walter Bright wrote:

 On 5/8/2015 12:45 AM, weaselcat wrote:

 some of these really are klunky though.


 Nobody's ever satisfied. Doesn't mean the tools aren't 
 effective, and doesn't mean a "complete lack of tooling".

 I find:

    dmd std/algorithm -main -unittest -cov

 quite far removed from 'klunky'. How do you do it in [pick a 
 language]?



 e.g, if D's built-in unit testing is so good, why are there 
 eight packages for
 unit testing on dub?


 I haven't used them, and so have no opinion on them. I use the 
 builtin capability every day I am working on D code, and find 
 it easy and indispensable.


Well, I have to say that I love what D has done with unit tests 
and code coverage. It's not perfect, but the fact that it's 
built-in makes it extremely easy to use and embarrassing if you 
don't. And on the whole, I really don't see the need for some of 
the kinds of features that others complain about D missing. 
That's not to say that there's not value in some of those 
features, but I think that the language itself has a very good 
foundation for unit testing with covers the 90% case, and if 
others want to create their own unit testing frameworks to handle 
more complex cases, they're certainly free to do so.

For larger projects, I'd probably want to be able to have names 
for the unittest blocks and have the be printed as the tests run, 
but that's easy enough to add (albeit possibly a bit tedious). 
So, I really haven't found D's built-in unit test framework to be 
particularly lacking, and based on discussions on it in the past, 
I think that it's quite clear that there would be a lot of 
disagreement on how it should be changed if we were looking to 
add to the language itself some of the features that those 3rd 
party unit test frameworks have.

Certainly, being able to just put unit tests in my modules rather 
than having to find and link against a 3rd party unit test 
framework is a definite improvement over other languages that 
I've used. And even if someone prefers one of the unit test 
frameworks on code.dlang.org, it's not like that's any worse than 
other languages where you _have_ to use a 3rd party unit test 
framework. So, while I can understand someone wanting the 
built-in unit test framework to do more and being frustrated with 
that is understandable, I think that a bit of perspective is in 
order. After all, what other language has unit tests built in at 
all?

- Jonathan M Davis
May 08 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/8/2015 2:52 AM, Jonathan M Davis wrote:

 the fact that it's built-in makes it extremely easy to use and embarrassing if
you don't.


That's the game changing part, and what's missing from other languages.



 After all, what other language has unit tests built in at all?


Yup. I haven't done anything remotely resembling an exhaustive search, but Go 
and Ruby have testing as add-on packages. JUnit is an add-on the user must 
download and install. There's not a word in the C and C++ specs about unit 
testing. And so on.

Unit testing, coverage analysis, documentation generation, and profiling are 
very deliberately built in to the core compiler and language. They are always 
there, always available, and always the right version.

One can dismiss that as trivia, that any professional won't be stopped by
having 
to find the right download, install, and integration procedure. But the reality 
is that having this all built-in has seismically changed how D code is written.
May 08 2015
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 8 May 2015 at 10:56:22 UTC, Walter Bright wrote:

 On 5/8/2015 2:52 AM, Jonathan M Davis wrote:

 the fact that it's built-in makes it extremely easy to use and 
 embarrassing if you don't.


 That's the game changing part, and what's missing from other 
 languages.



 After all, what other language has unit tests built in at all?


 Yup. I haven't done anything remotely resembling an exhaustive 
 search, but Go and Ruby have testing as add-on packages. JUnit 
 is an add-on the user must download and install. There's not a 
 word in the C and C++ specs about unit testing. And so on.

 Unit testing, coverage analysis, documentation generation, and 
 profiling are very deliberately built in to the core compiler 
 and language. They are always there, always available, and 
 always the right version.

 One can dismiss that as trivia, that any professional won't be 
 stopped by having to find the right download, install, and 
 integration procedure. But the reality is that having this all 
 built-in has seismically changed how D code is written.


True. If it ain't easy to use, nobody will use it.

First I was a bit sceptical about the unittests, cos you have 
tests for the finished product anyway ... But unittests are

a) a documentation of the code and
b) simple and easy to use in D
c) make you think about your code more carefully.

c) is very important. Designing a unittest often makes me realize 
that there are shortcomings in my code, or make me think of 
further possibilities. Having coverage, unittests and performance 
tests built in makes you think more about your code in general. 
Take a program that starts out as a command line tool like "open 
file, parse, analyze". You start with something that just 
"works", you need it fast, you need it now. But it doesn't harm 
you to add a unittest (the same stuff you would more or less test 
for anyway with `writeln(output)`. Your little tool becomes more 
reliable and well-documented, and can later grow into something 
bigger. I know, you should treat a simple command line tool as 
something that might possibly grow anyway, but D makes it so much 
easier. And let's be honest, we're all human, we're all lazy. If 
we weren't lazy, we wouldn't bother with programming - after all 
what else is programming than having a machine do something for 
you.
May 08 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Friday, 8 May 2015 at 09:52:06 UTC, Jonathan M Davis wrote:

 That's not to say that there's not value in some of those 
 features, but I think that the language itself has a very good 
 foundation for unit testing with covers the 90% case, and if 
 others want to create their own unit testing frameworks to 
 handle more complex cases, they're certainly free to do so.


My estimation is 20% - they apply to simplistic self-contained 
libraries like phobos and warp. My impression is not much code 
falls in this category. Even dmd doesn't, and it's already rather 
simplistic.


 Certainly, being able to just put unit tests in my modules 
 rather than having to find and link against a 3rd party unit 
 test framework is a definite improvement over other languages 
 that I've used.


Inability to use 3rd party libraries is a packaging (tooling) 
issue, though.
May 08 2015
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 8 May 2015 at 14:16:27 UTC, Kagamin wrote:

 On Friday, 8 May 2015 at 09:52:06 UTC, Jonathan M Davis wrote:

 That's not to say that there's not value in some of those 
 features, but I think that the language itself has a very good 
 foundation for unit testing with covers the 90% case, and if 
 others want to create their own unit testing frameworks to 
 handle more complex cases, they're certainly free to do so.


 My estimation is 20% - they apply to simplistic self-contained 
 libraries like phobos and warp. My impression is not much code 
 falls in this category. Even dmd doesn't, and it's already 
 rather simplistic.


When the tests aren't self-contained, you're not really doing 
unit tests anymore. That's getting more into component test 
territory and the like, and that's a whole other ballgame.

- Jonathan M Davis
May 08 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Friday, 8 May 2015 at 08:51:24 UTC, Walter Bright wrote:

 On 5/8/2015 12:45 AM, weaselcat wrote:

 some of these really are klunky though.


 Nobody's ever satisfied. Doesn't mean the tools aren't 
 effective, and doesn't mean a "complete lack of tooling".


I think it's important to air grievances with the language 
because it won't get better by sticking our heads in the sand. 
Stating things like "unit tests could have better reporting 
capabilities" etc, sparks a good discussion on how to improve 
them, and I think this thread is proof of that.
May 08 2015
parent reply "bachmeier" <no spam.net> writes:
On Saturday, 9 May 2015 at 02:08:54 UTC, weaselcat wrote:

 On Friday, 8 May 2015 at 08:51:24 UTC, Walter Bright wrote:

 On 5/8/2015 12:45 AM, weaselcat wrote:

 some of these really are klunky though.


 Nobody's ever satisfied. Doesn't mean the tools aren't 
 effective, and doesn't mean a "complete lack of tooling".


 I think it's important to air grievances with the language 
 because it won't get better by sticking our heads in the sand. 
 Stating things like "unit tests could have better reporting 
 capabilities" etc, sparks a good discussion on how to improve 
 them, and I think this thread is proof of that.


I think it's good to have an honest discussion about these 
issues, but there is also a tendency of some to go overboard. At 
times it crosses into trolling territory where they'll post 
something negative just to be posting something negative.

One incident that stands out followed an announcement that got a 
lot of press for D, and someone thought it was a good use of his 
time to post a laundry list of problems with the language in that 
thread, much of which was pure crap. Those posts do not 
contribute anything.
May 09 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Saturday, 9 May 2015 at 09:31:10 UTC, bachmeier wrote:

 On Saturday, 9 May 2015 at 02:08:54 UTC, weaselcat wrote:

 On Friday, 8 May 2015 at 08:51:24 UTC, Walter Bright wrote:

 On 5/8/2015 12:45 AM, weaselcat wrote:

 some of these really are klunky though.


 Nobody's ever satisfied. Doesn't mean the tools aren't 
 effective, and doesn't mean a "complete lack of tooling".


 I think it's important to air grievances with the language 
 because it won't get better by sticking our heads in the sand. 
 Stating things like "unit tests could have better reporting 
 capabilities" etc, sparks a good discussion on how to improve 
 them, and I think this thread is proof of that.


 I think it's good to have an honest discussion about these 
 issues, but there is also a tendency of some to go overboard. 
 At times it crosses into trolling territory where they'll post 
 something negative just to be posting something negative.

 One incident that stands out followed an announcement that got 
 a lot of press for D, and someone thought it was a good use of 
 his time to post a laundry list of problems with the language 
 in that thread, much of which was pure crap. Those posts do not 
 contribute anything.


There is a tendency to bash and trash D for not having the exact 
same feature that some other language has, or for not having a 
tool that exists for some other language. This often gives the 
impression that D is unusable and complete crap, unless, of 
course, it will get feature X demanded by user Y. This type of 
discussion is not constructive, but guided by personal likes and 
dislikes and only creates a lot of noise with no real results.

There is always room for improvement in software. All programs 
could be better, all tools could be better. But that something 
could be better doesn't mean that it's crap.
May 09 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/9/15 5:28 AM, Chris wrote:

 There is a tendency to bash and trash D for not having the exact same
 feature that some other language has, or for not having a tool that
 exists for some other language. This often gives the impression that D
 is unusable and complete crap, unless, of course, it will get feature X
 demanded by user Y. This type of discussion is not constructive, but
 guided by personal likes and dislikes and only creates a lot of noise
 with no real results.

 There is always room for improvement in software. All programs could be
 better, all tools could be better. But that something could be better
 doesn't mean that it's crap.


Well put. A few thoughts about that:

1. Some of these, even some of the more egregious ones, come from people 
who by their acts seem to genuinely enjoy the language and contribute to 
it. Are we taking the notion of tough love a bit too seriously?

2. There's a lot of resistance to the leadership saying positive things 
about the language. Soon as Walter replied that our toolchain isn't that 
bad, others replied with all they could to counter him - in what's now 
quite a predictable pattern. My interpretation of this phenomenon is 
that the leadership tooting its own horn makes people nervous ("are 
these guys in denial? so no more improvements on this stuff?" etc). I 
guess we should do less of it.

3. We need to improve the curb appeal of D.


Andrei
May 09 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, May 09, 2015 at 09:02:27AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:

 On 5/9/15 5:28 AM, Chris wrote:

There is a tendency to bash and trash D for not having the exact same
feature that some other language has, or for not having a tool that
exists for some other language. This often gives the impression that
D is unusable and complete crap, unless, of course, it will get
feature X demanded by user Y. This type of discussion is not
constructive, but guided by personal likes and dislikes and only
creates a lot of noise with no real results.

There is always room for improvement in software. All programs could
be better, all tools could be better. But that something could be
better doesn't mean that it's crap.


 
 Well put. A few thoughts about that:
 
 1. Some of these, even some of the more egregious ones, come from
 people who by their acts seem to genuinely enjoy the language and
 contribute to it. Are we taking the notion of tough love a bit too
 seriously?
 
 2. There's a lot of resistance to the leadership saying positive
 things about the language. Soon as Walter replied that our toolchain
 isn't that bad, others replied with all they could to counter him - in
 what's now quite a predictable pattern. My interpretation of this
 phenomenon is that the leadership tooting its own horn makes people
 nervous ("are these guys in denial? so no more improvements on this
 stuff?" etc). I guess we should do less of it.
 
 3. We need to improve the curb appeal of D.


[...]

FWIW, I don't believe that the leadership tooting its own horn makes
people nervous. Nervousness does not trigger the kind of ascerbic
comments.

I think the *real* cause of these comments is the perception (whether or
not it has basis in reality is up for debate) that certain long-standing
nagging problems have not yet been fixed, and doesn't seem like they
will be fixed anytime soon, and yet statements are made that seem (in
the eyes of the commenter) to imply that these problems aren't there.
These problems may be minor, peripheral, or not very important in the
grand scheme of things, but they are nevertheless very obvious to the
commenter because they encounter it frequently, or had a bad experience
with it, like a mosquito in the room that causes endless annoyance and
increasing frustration even if its worst effect is a mere itch at the
end of the day.

Blanket statements about how good D (or that particular part of D) is
may be wrongly taken as a denial of the existence of said minor (or
not-so-minor) problem along with its associated frustrating experience,
which aggravates the commenter to the point of posting an ascerbic
response.

Another cause is that D has a core that's so ideal -- perhaps too ideal
-- that people have developed an expectation that *everything* in D must
be perfect, or else. They are not satisfied with a partial solution that
meets 99% of the cases; they want 100.000%. The problem is, there is no
single solution that solves every possible case.  Nobody agrees on how
to get from the 99% to the 100%. Everyone has a different ideal of what
perfection means. So no matter which route you choose, *somebody* is
bound to get upset. Then when the chosen solution has been implemented
and touted, the people who didn't agree with that solution get ticked
off and react negatively.

How to solve this, I don't know. That's up to the leadership to solve.
;-) But at least let's be clear that this has nothing to do with
nervousness or tough love or anything of that sort.


T

-- 
WINDOWS = Will Install Needless Data On Whole System -- CompuMan
May 09 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/9/15 10:30 AM, H. S. Teoh via Digitalmars-d wrote:

 I think the *real* cause of these comments is the perception (whether or
 not it has basis in reality is up for debate) that certain long-standing
 nagging problems have not yet been fixed, and doesn't seem like they
 will be fixed anytime soon, and yet statements are made that seem (in
 the eyes of the commenter) to imply that these problems aren't there.


Yah, that's what I meant to say. Thanks for putting it so clearly.


 Blanket statements about how good D (or that particular part of D) is
 may be wrongly taken as a denial of the existence of said minor (or
 not-so-minor) problem along with its associated frustrating experience,
 which aggravates the commenter to the point of posting an ascerbic
 response.


Again very well put.


 Another cause is that D has a core that's so ideal -- perhaps too ideal
 -- that people have developed an expectation that *everything* in D must
 be perfect, or else. They are not satisfied with a partial solution that
 meets 99% of the cases; they want 100.000%. The problem is, there is no
 single solution that solves every possible case.  Nobody agrees on how
 to get from the 99% to the 100%. Everyone has a different ideal of what
 perfection means. So no matter which route you choose, *somebody* is
 bound to get upset. Then when the chosen solution has been implemented
 and touted, the people who didn't agree with that solution get ticked
 off and react negatively.

 How to solve this, I don't know. That's up to the leadership to solve.
 ;-) But at least let's be clear that this has nothing to do with
 nervousness or tough love or anything of that sort.


One other aspect might have to do with ambition. We have great ambitions 
for D that are very far ahead where we are right now with it. Yet 
tooting our own horn, even though it's only mentioned as work in 
progress, is considered "yah, we're happy with where we are, all good" etc.


Andrei
May 09 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 7 May 2015 at 22:27:57 UTC, Walter Bright wrote:

 But let's not forget the meat and potatoes on our plate while 
 looking at our neighbor's salad dressing.


Yes, but I think people actually mean an IDE when they say that 
tooling is the main issue. Then again, many C/C++ people swear by 
emacs/gdb so tooling is not the primary issue!

And people don't pick a language because of a testing framework…

Language, compiler, runtime…
May 08 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/8/2015 1:16 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 And people don't pick a language because of a testing framework…


Which is why I need to point out just how productivity boosting -unittest and 
-cov are.
May 08 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 8 May 2015 at 08:45:07 UTC, Walter Bright wrote:

 On 5/8/2015 1:16 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 And people don't pick a language because of a testing 
 framework…


 Which is why I need to point out just how productivity boosting 
 -unittest and -cov are.


D unittests can be neat for simpler libraries, but they also make 
code harder to browse. Phobos source code clearly suffers from it.

So I'd rather have them separate and have testing-support built 
into the IDE instead. I find that cleaner as unit-tests are 
actually not part of the semantical language, just part of the D 
syntax...

You are probably right that people use them more when they are 
"shipped with the product", though. Whether you ship the compiler 
or a bundle (IDE).
May 08 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 8 May 2015 at 13:31:38 UTC, Ola Fosheim Grøstad wrote:

 On Friday, 8 May 2015 at 08:45:07 UTC, Walter Bright wrote:

 On 5/8/2015 1:16 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 And people don't pick a language because of a testing 
 framework…


 Which is why I need to point out just how productivity 
 boosting -unittest and -cov are.


 D unittests can be neat for simpler libraries, but they also 
 make code harder to browse. Phobos source code clearly suffers 
 from it.

 So I'd rather have them separate and have testing-support built 
 into the IDE instead. I find that cleaner as unit-tests are 
 actually not part of the semantical language, just part of the 
 D syntax...

 You are probably right that people use them more when they are 
 "shipped with the product", though. Whether you ship the 
 compiler or a bundle (IDE).


I like unittests in phobos and other libraries, because they 
immediately show me how to use the code, and I like how simple it 
is:

dub --build=unittest

or

dmd myfile.d -unittest

Be honest, have you written unittests for each your Python 
scripts, for each of your command line tools? D makes it easy for 
you.

The only drawback is that sometimes the logic of a program does 
not allow to test every little bit, especially when handling 
files is concerned. But overall D in general makes me more "code 
aware" in many respects, be it performance, code hygiene or 
re-usability. And it helps that the compiler ships with a lot of 
flags that help me to analyze my code.
May 08 2015
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 8 May 2015 at 14:00:01 UTC, Chris wrote:

 On Friday, 8 May 2015 at 13:31:38 UTC, Ola Fosheim Grøstad 
 wrote:

 On Friday, 8 May 2015 at 08:45:07 UTC, Walter Bright wrote:

 On 5/8/2015 1:16 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 And people don't pick a language because of a testing 
 framework…


 Which is why I need to point out just how productivity 
 boosting -unittest and -cov are.


 D unittests can be neat for simpler libraries, but they also 
 make code harder to browse. Phobos source code clearly suffers 
 from it.

 So I'd rather have them separate and have testing-support 
 built into the IDE instead. I find that cleaner as unit-tests 
 are actually not part of the semantical language, just part of 
 the D syntax...

 You are probably right that people use them more when they are 
 "shipped with the product", though. Whether you ship the 
 compiler or a bundle (IDE).


 I like unittests in phobos and other libraries, because they 
 immediately show me how to use the code, and I like how simple 
 it is:

 dub --build=unittest

 or

 dmd myfile.d -unittest

 Be honest, have you written unittests for each your Python 
 scripts, for each of your command line tools? D makes it easy 
 for you.

 The only drawback is that sometimes the logic of a program does 
 not allow to test every little bit, especially when handling 
 files is concerned. But overall D in general makes me more 
 "code aware" in many respects, be it performance, code hygiene 
 or re-usability. And it helps that the compiler ships with a 
 lot of flags that help me to analyze my code.


The funny thing is that people keep complaining about the lack of 
tools for D, and when a tool is built into the language they say 
"That tool shouldn't be part of the language". Yet, if it were 
omitted, people would say "Why doesn't D have this tool built 
in?". Human nature, I guess.
May 08 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/8/15 7:03 AM, Chris wrote:

 The funny thing is that people keep complaining about the lack of tools
 for D, and when a tool is built into the language they say "That tool
 shouldn't be part of the language". Yet, if it were omitted, people
 would say "Why doesn't D have this tool built in?". Human nature, I guess.


Nicely put :o). I think the right conclusion to this discussion is to 
fall in neither "D has no tooling", nor "D's tooling is great" extreme. 
As it often happens, there's no shortage of ideas on things we could 
work on, more so than folks ready to work on them. So... have at it! -- 
Andrei
May 08 2015
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 8 May 2015 at 14:04:00 UTC, Chris wrote:

 The funny thing is that people keep complaining about the lack 
 of tools for D, and when a tool is built into the language they 
 say "That tool shouldn't be part of the language". Yet, if it 
 were omitted, people would say "Why doesn't D have this tool 
 built in?". Human nature, I guess.


Well, I am not saying "why doesn't D have any tools built in?" or 
even "why doesn't D have a great IDE?". I'm saying that tools are 
not as critical, they only affect a specific demographic, but not 
the bottom line.

There is a large potential demographic base that are quite 
content with barebones tooling (emacs/unix), so if you by 
improving the language/runtime can appeal more of those 
developers you also have a baseline for extending into other 
demographics. Extending into the "spoiled kids" demographic will 
lead  exactly to what you'd expect… more work, more demands.

"Tooling" and "testing" are very opinionated, fashionable and 
situated topics. Much more so than language semantics.
May 08 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/8/2015 7:03 AM, Chris wrote:

 The funny thing is that people keep complaining about the lack of tools for D,
 and when a tool is built into the language they say "That tool shouldn't be
part
 of the language". Yet, if it were omitted, people would say "Why doesn't D have
 this tool built in?". Human nature, I guess.


I see it slightly differently. If the tool is built in to the language, people 
do not regard it as a tool anymore when preparing a mental checklist of 
"available tooling".

---- Warning! Another Boring Walter Cutaway -------------

It reminds me of back when we were selling the Zortech C++ compiler, we
included 
complete runtime library source with the compiler. This was back in the days 
when most compilers' library source code was a closely held trade secret.

Nobody noticed that we included the runtime library source.

Then, one day, Borland decided to make their previously trade secret library 
source code available as a separate purchase. They did an amazing job marketing 
this, and journalists everywhere celebrated the forward thinking breakthrough. 
Even in magazine compiler roundup reviews, the journalists would breathlessly 
note that one could now buy Borland's library source code, but Zortech C++ 
including it for free was never mentioned.

We threw in the towel, and made the library source code a separately priced add 
on. This was a big success for us!

No, I'm not suggesting we unbundle unit testing, Ddoc, coverage analysis, 
profiling, etc., into separate tools for marketing purposes. I'm just bemused
by 
how perceptions work.

------------------------------------------------------
May 08 2015
next sibling parent "Laeeth Isharc" <nospamlaeeth nospamlaeeth.com> writes:
 ---- Warning! Another Boring Walter Cutaway -------------


Very interesting story.


 No, I'm not suggesting we unbundle unit testing, Ddoc, coverage 
 analysis, profiling, etc., into separate tools for marketing 
 purposes. I'm just bemused by how perceptions work.


Affect is like an iceberg - 90% below conscious awareness - but 
it shapes global perceptions, processing, and decision-making in 
the brain.  (See  Camerer et al review paper).

What is not widely appreciated even by putative experts is that 
affect shapes perceptions themselves, not just the hedonic 
evaluation of those perceptions.  And people feel a certain way 
towards D and look for reasons to explain their affect - it's 
affect that is primary, not the rationalizations given.  But 
affect towards entities and institutions can and does change, 
sometimes for mysterious reasons (although the 'facts' tend to 
change in line with the perceptions).  This is all in gestalt 
psychology, and some of the work on mass psychological behaviour 
done since then.

This is also a neglected facet of financial market behaviour.  In 
2002 Germany was the sick man of Europe according to the 
Economist.  But really, this was the moment of greatest error in 
articulating that perception, because she was at that moment 
beginning reforms that would lead to her prosperity today.  It's 
how one responds to challenges that is important.

Perhaps D might be on a similar path (not sick, but maturing, 
with concern over immaturity not fitting the nascent blossoming 
of new tooling, library interfaces, GC improvements, memory 
allocators, etc).
May 09 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 8 May 2015 at 19:59:35 UTC, Walter Bright wrote:

 On 5/8/2015 7:03 AM, Chris wrote:

 The funny thing is that people keep complaining about the lack 
 of tools for D,
 and when a tool is built into the language they say "That tool 
 shouldn't be part
 of the language". Yet, if it were omitted, people would say 
 "Why doesn't D have
 this tool built in?". Human nature, I guess.


 I see it slightly differently. If the tool is built in to the 
 language, people do not regard it as a tool anymore when 
 preparing a mental checklist of "available tooling".

 ---- Warning! Another Boring Walter Cutaway -------------

 It reminds me of back when we were selling the Zortech C++ 
 compiler, we included complete runtime library source with the 
 compiler. This was back in the days when most compilers' 
 library source code was a closely held trade secret.

 Nobody noticed that we included the runtime library source.

 Then, one day, Borland decided to make their previously trade 
 secret library source code available as a separate purchase. 
 They did an amazing job marketing this, and journalists 
 everywhere celebrated the forward thinking breakthrough. Even 
 in magazine compiler roundup reviews, the journalists would 
 breathlessly note that one could now buy Borland's library 
 source code, but Zortech C++ including it for free was never 
 mentioned.

 We threw in the towel, and made the library source code a 
 separately priced add on. This was a big success for us!

 No, I'm not suggesting we unbundle unit testing, Ddoc, coverage 
 analysis, profiling, etc., into separate tools for marketing 
 purposes. I'm just bemused by how perceptions work.

 ------------------------------------------------------


I love these war stories :)
May 09 2015
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 08/05/2015 15:03, Chris wrote:

 The funny thing is that people keep complaining about the lack of tools
 for D, and when a tool is built into the language they say "That tool
 shouldn't be part of the language". Yet, if it were omitted, people
 would say "Why doesn't D have this tool built in?". Human nature, I guess.


That's because some developers are, well, idiots (that's human nature). 
Or to put it less bluntly, some developers have idiot ideas about what 
should be done in the language.

This is important for us to recognize, because it should be an important 
skill of the D leaders/designers to recognize which of these ideas are 
good, and which are not. We shouldn't follow every user's suggestion, 
even if there is a vocal minority behind it. It's not a case of "the 
customer is always right" here.


In this particular case, about tooling, my general feeling is that 
tooling that benefits the whole community if more developers all use the 
same tool, should be included in the basic D distribution. So stuff like 
formatting tool, testing framework, build system (DUB for example), etc. 
. It helps one developer if other developers use the same standard here, 
with regards to these tools, because then they are compatible and can be 
reused.

For other kinds of tools, say IDEs for example, it really doesn't affect 
me at all what IDEs other developers use, it makes no impact in the 
generated code. So it doesn't have to be included in the D distribution. 
(doesn't mean it can't though, it's not a strict rule)

Java for example, does not ship any IDE with the standard Java 
distribution, even though Oracle does work on an IDE of their own - 
(Netbeans).

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jun 03 2015
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 3 June 2015 at 10:40:14 UTC, Bruno Medeiros wrote:

 On 08/05/2015 15:03, Chris wrote:

 The funny thing is that people keep complaining about the lack 
 of tools
 for D, and when a tool is built into the language they say 
 "That tool
 shouldn't be part of the language". Yet, if it were omitted, 
 people
 would say "Why doesn't D have this tool built in?". Human 
 nature, I guess.


 That's because some developers are, well, idiots (that's human 
 nature). Or to put it less bluntly, some developers have idiot 
 ideas about what should be done in the language.

 This is important for us to recognize, because it should be an 
 important skill of the D leaders/designers to recognize which 
 of these ideas are good, and which are not. We shouldn't follow 
 every user's suggestion, even if there is a vocal minority 
 behind it. It's not a case of "the customer is always right" 
 here.


 In this particular case, about tooling, my general feeling is 
 that tooling that benefits the whole community if more 
 developers all use the same tool, should be included in the 
 basic D distribution. So stuff like formatting tool, testing 
 framework, build system (DUB for example), etc. . It helps one 
 developer if other developers use the same standard here, with 
 regards to these tools, because then they are compatible and 
 can be reused.

 For other kinds of tools, say IDEs for example, it really 
 doesn't affect me at all what IDEs other developers use, it 
 makes no impact in the generated code. So it doesn't have to be 
 included in the D distribution. (doesn't mean it can't though, 
 it's not a strict rule)

 Java for example, does not ship any IDE with the standard Java 
 distribution, even though Oracle does work on an IDE of their 
 own - (Netbeans).


You can download the SDK together with Netbeans.

It is also the standard IDE on Solaris.
Jun 03 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/8/2015 7:00 AM, Chris wrote:

 The only drawback is that sometimes the logic of a program does not allow to
 test every little bit, especially when handling files is concerned.


This is an interesting problem, one that I faced with Warp.

The solution was to make the function being tested a function template. Then,
in 
the unit test I replace the 'file' argument to the function with a static array 
of test data.

The term for it is 'type mocking', and it's fairly well explored territory.
What 
I find most intriguing about it is it results in D programs consisting largely 
of template functions rather than plain functions.
May 08 2015
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-05-08 21:45, Walter Bright wrote:


 This is an interesting problem, one that I faced with Warp.

 The solution was to make the function being tested a function template.
 Then, in the unit test I replace the 'file' argument to the function
 with a static array of test data.


I don't really like that approach. The need to change something to a 
template just to make it testable. That's the beaut of dynamic typing 
and especially Ruby.

In Ruby I can replace a given method on any object very easily, even on 
just one instance.

obj = Object.new

def obj.to_s
   'foo'
end

obj.to_s == 'foo'
Object.new.to_s != 'foo'

This is perfect for mocking and stubbing.

-- 
/Jacob Carlborg
May 11 2015
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 8 May 2015 at 19:45:35 UTC, Walter Bright wrote:

 On 5/8/2015 7:00 AM, Chris wrote:

 The only drawback is that sometimes the logic of a program 
 does not allow to
 test every little bit, especially when handling files is 
 concerned.


 This is an interesting problem, one that I faced with Warp.

 The solution was to make the function being tested a function 
 template. Then, in the unit test I replace the 'file' argument 
 to the function with a static array of test data.

 The term for it is 'type mocking', and it's fairly well 
 explored territory. What I find most intriguing about it is it 
 results in D programs consisting largely of template functions 
 rather than plain functions.


Hm, I was thinking of something like that, however, it gets more 
and more complicated if you have e.g. a class that uses another 
class etc.

class Data // A singleton
{
   // stores paths to resources etc.
}

class Loader
{
   this()
    this.data = Data.getInstance();
   // Loads files and caches them in memory
}

class Process
{
   // Uses cached data
}

It ain't easy to unit test Process, but even Loader and Data can 
be tricky to unit test, because all of them depend on input from 
the outside.

./runprogram --config="config.json"

 Data.read("config.json")
 Loader.load(resources from config.json)
 Process.use(data loaded)


For cases like this, it's better to have an external test script.
May 11 2015
parent reply "Kagamin" <spam here.lot> writes:
On Monday, 11 May 2015 at 09:31:34 UTC, Chris wrote:

 Hm, I was thinking of something like that, however, it gets 
 more and more complicated if you have e.g. a class that uses 
 another class etc.

 class Data // A singleton
 {
   // stores paths to resources etc.
 }

 class Loader
 {
   this()
    this.data = Data.getInstance();
   // Loads files and caches them in memory
 }

 class Process
 {
   // Uses cached data
 }

 It ain't easy to unit test Process, but even Loader and Data 
 can be tricky to unit test, because all of them depend on input 
 from the outside.


That's the reason for IoC design; it's similar to ranges in a 
sense that you feed the range with data instead of letting it 
figure out where to get that data on its own.
May 13 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 13 May 2015 at 08:26:35 UTC, Kagamin wrote:

 On Monday, 11 May 2015 at 09:31:34 UTC, Chris wrote:

 Hm, I was thinking of something like that, however, it gets 
 more and more complicated if you have e.g. a class that uses 
 another class etc.

 class Data // A singleton
 {
  // stores paths to resources etc.
 }

 class Loader
 {
  this()
   this.data = Data.getInstance();
  // Loads files and caches them in memory
 }

 class Process
 {
  // Uses cached data
 }

 It ain't easy to unit test Process, but even Loader and Data 
 can be tricky to unit test, because all of them depend on 
 input from the outside.


 That's the reason for IoC design; it's similar to ranges in a 
 sense that you feed the range with data instead of letting it 
 figure out where to get that data on its own.


However, the data comes from somewhere outside the program, and 
although you can IoC most parts of a program _after_ it's been 
fed the data, the initial input section is not easily unit tested 
(i.e. unit test in D).

Unit tests only work for the data processing logic inside a unit 
after the program has received the data from the outside. But the 
initial acquisition of data is outside the scope of these unit 
tests. Thus, there are always bits and pieces that cannot be 
unit-tested like e.g. loading files.
May 14 2015
parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 14 May 2015 at 13:22:21 UTC, Chris wrote:

 However, the data comes from somewhere outside the program, and 
 although you can IoC most parts of a program _after_ it's been 
 fed the data, the initial input section is not easily unit 
 tested (i.e. unit test in D).


Gathering parts together is integration point, and unit tests 
don't test integration. In your example you would be able to test 
the Process class. If you are unsure Loader can't parse files - 
that can be tested without files, streams are enough.
May 14 2015
parent reply "Victor" <victor.v.carvalho gmail.com> writes:
I think that besides all problems D have, the only one that 
mattered most and never was fixed was proper ARM support. Since 
dmd 1 I'm dreaming to ditch C++ for D on game development but 
this day never comes as it seems that there's always 
priorities(mostly justified) that postpone this. So I had to move 
to rust, which I'm my opinion is a subpar language comparing with 
D, but at least is moving on this direction.
May 14 2015
parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 14 May 2015 15:00:32 +0000
schrieb "Victor" <victor.v.carvalho gmail.com>:


 I think that besides all problems D have, the only one that 
 mattered most and never was fixed was proper ARM support.


"proper arm support" depends on your definition of "arm support". GDC
supports ARM/GLibc/Linux just as well as X86/GlibC/Linux. Only
ARM/Android, ARM/iOS and ARM/BareMetal are not supported. That's more
an OS than processor architecture thing though.
May 14 2015
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 14 May 2015 at 17:40, Johannes Pfau via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Am Thu, 14 May 2015 15:00:32 +0000
 schrieb "Victor" <victor.v.carvalho gmail.com>:


 I think that besides all problems D have, the only one that
 mattered most and never was fixed was proper ARM support.


 "proper arm support" depends on your definition of "arm support". GDC
 supports ARM/GLibc/Linux just as well as X86/GlibC/Linux. Only
 ARM/Android, ARM/iOS and ARM/BareMetal are not supported. That's more
 an OS than processor architecture thing though.



We still have one disrepency in runtime though (LTR vs. RTL):
https://github.com/D-Programming-Language/dmd/pull/4035

I say that, however, there are infact two discrepencies (this exists
on GDC x86 vs DMD x86):
https://github.com/D-Programming-Language/dmd/pull/3670

I'll be happy the day DMD stops using it's own (non-conforming to spec) ABI.

Iain.
May 14 2015
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 7 May 2015 at 22:27:57 UTC, Walter Bright wrote:

 But let's not forget the meat and potatoes on our plate while 
 looking at our neighbor's salad dressing.


I decided to line up our potatoes on a nice new wiki page:

http://wiki.dlang.org/Development_tools
May 08 2015
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 8 May 2015 at 15:47:11 UTC, Vladimir Panteleev wrote:

 On Thursday, 7 May 2015 at 22:27:57 UTC, Walter Bright wrote:

 But let's not forget the meat and potatoes on our plate while 
 looking at our neighbor's salad dressing.


 I decided to line up our potatoes on a nice new wiki page:

 http://wiki.dlang.org/Development_tools


Good man yourself!
May 08 2015
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/8/2015 8:47 AM, Vladimir Panteleev wrote:

 On Thursday, 7 May 2015 at 22:27:57 UTC, Walter Bright wrote:

 But let's not forget the meat and potatoes on our plate while looking at our
 neighbor's salad dressing.


 I decided to line up our potatoes on a nice new wiki page:

 http://wiki.dlang.org/Development_tools


:-)

Thanks for doing this, it's nice.
May 08 2015
prev sibling parent "albatroz" <rmcjustino gmail.com> writes:
Would like to suggest strip to be added to the page. It makes 
wonders to the final executable.

On Friday, 8 May 2015 at 15:47:11 UTC, Vladimir Panteleev wrote:

 On Thursday, 7 May 2015 at 22:27:57 UTC, Walter Bright wrote:

 But let's not forget the meat and potatoes on our plate while 
 looking at our neighbor's salad dressing.


 I decided to line up our potatoes on a nice new wiki page:

 http://wiki.dlang.org/Development_tools
May 11 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
Sometime, one got to be harsh, but the truth is that D have many 
mostly implemented features, often falling short in some cases or 
working in a way that make no sense.

On Thursday, 7 May 2015 at 22:27:57 UTC, Walter Bright wrote:

 On 5/7/2015 5:16 AM, d user wrote:

 the truth is, one of the biggest things holding D back from 
 mass adoption is the
 complete lack of tooling compared to  basically every other 
 mainstream language.


 D has some excellent tools that are generally nonstandard, 
 klunky or nonexistent in other languages:

 1. unit testing


The way D runs tests before running the app does not make any 
sense. The way you can't run them for a module without a main 
makes no sense. The way you end runnign all kind of test with the 
ones you are interested in makes no sense.

Yes D has easy syntax to make unitests. Meaning it is a great 
language in that regard.

But it has horrible tooling that can be regarded at best as a 
glorified hack that is mostly useless at scale.


 2. documentation generation


The fact this is backed into the language the way it is mostly 
show a lack of separation of concerns. That is a side effect of 
the fact the frontend is completely monolithic.

You don't need to bake that into the language when the compiler 
can feed symbol information to 3rd party tools.


 3. coverage analysis


I'm not sure how Go and Rust stand on that one, but all 
mainstream languages have descent code coverage, with the added 
bonus that this is very well integrated with the rest of the 
tooling (tolling which is non existent in D). I would not put 
this has a string point of D. Not bad either, but definitively 
what you'd expect from any serious language.

Last but not least, things like:
if (foo && bar) ...;

Contains 2 branches. The output we have to not provide data about 
this, which makes the coverage infos lacking in some regard.

In java for instance, I could run tests (and not the whole 
program with test at startup) and get all the coverage infos 
directly in my editor with colors and stuff, include things like 
short circuit for boolean operators, which we don't have. We are 
miles (kilometers damn it !) away from this level of support.


 4. profiler


Same things, this is a standard tool nowaday for any language 
worth considering. In fact, even if we had no specific support in 
D for it, C/C++ tooling could probably do it for us to some 
extent.


 5. and as of last week, a memory usage profiler


Good memory allocator like tcmalloc and/or jemalloc have detailed 
output. And if we go back to java, you can even observe things in 
a graphic way in real time concurrently to the application 
running ! Once again, we are not even remotely close to anything 
like this.
May 08 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/8/2015 2:51 PM, deadalnix wrote:

 1. unit testing


 The way D runs tests before running the app does not make any sense.


It works perfectly fine and obviates the need to create a separate test harness.



 The way you can't run them for a module without a main makes no sense.


     dmd foo -unittest -main



 The way you end runnign all kind of test with the ones you are interested in
makes no sense.


    dmd std/path -unittest -main

runs just the unit tests in std/path. You can run tests in some modules, but
not 
others, with:

    dmd -c a b c -unittest
    dmd d e f a.o
    ./d



 2. documentation generation


 The fact this is backed into the language the way it is mostly show a lack of
 separation of concerns.


It means it is always there and always the correct version.



 That is a side effect of the fact the frontend is completely monolithic.


Has nothing to do with how usable a tool is.



 You don't need to bake that into the language when the compiler can feed symbol
 information to 3rd party tools.


D worked with 3rd party doc tools before Ddoc. The result was that maybe 1 or 2 
people ever used such tools. You weren't using D then - the Phobos
documentation 
was all of:

1. nonexistent
2. wrong
3. had no correlation with the APIs on the functions at all

Ddoc fixed all that. It's fine to gripe about this or that, but the results are 
undeniably a seismic improvement for D.



 3. coverage analysis


 I'm not sure how Go and Rust stand on that one, but all mainstream languages
 have descent code coverage, with the added bonus that this is very well
 integrated with the rest of the tooling (tolling which is non existent in D). I
 would not put this has a string point of D. Not bad either, but definitively
 what you'd expect from any serious language.


Try using gcov without going back to consult the manuals on it. Even if you
have 
it installed. Coverage analyzers in other languages that I checked all required 
finding and installing some extra package, then trying to figure out how to
hook 
it in.



 Last but not least, things like:
 if (foo && bar) ...;

 Contains 2 branches. The output we have to not provide data about this, which
 makes the coverage infos lacking in some regard.


Check before assuming -cov does it wrong. You'll find it counts the branches 
separately. It does sum them for the line count, but writing it as:

    if (foo &&
        bar)
         ....

you'll get two counts. What I am disappointed in is the repeated default 
assumption, without bothering to check, that D's tools are guilty until proven 
innocent.



 In java for instance, I could run tests (and not the whole program with test at
 startup) and get all the coverage infos directly in my editor with colors and
 stuff, include things like short circuit for boolean operators, which we don't
 have. We are miles (kilometers damn it !) away from this level of support.


Here's a slice of a D coverage report:


        |static if (allSatisfy!(hasMobileElements, R))
        |{
        |    RvalueElementType moveAt(size_t index)
        |    {
       6|        foreach (i, Range; R)
        |        {
        |            static if (isInfinite!(Range))
        |            {
0000000|                return .moveAt(source[i], index);
        |            }
        |            else
        |            {
       3|                immutable length = source[i].length;
       5|                if (index < length) return .moveAt(source[i], index);
       1|                    index -= length;
        |            }
        |        }
0000000|        assert(false);
        |    }
        |}
std\range\package.d is 91% covered

It's not in color, I concede that. Saying this report is "miles behind" is 
ludicrous, besides the incorrect statement that short circuits are not
supported.



 4. profiler


 Same things, this is a standard tool nowaday for any language worth
considering.
 In fact, even if we had no specific support in D for it, C/C++ tooling could
 probably do it for us to some extent.


Yah, I know about gprof. Try it (with a C or C++ program), without spending
time 
with the manuals. Here's the manual for D:

    dmd -profile foo



 5. and as of last week, a memory usage profiler


 Good memory allocator like tcmalloc and/or jemalloc have detailed output.


They don't come with C or C++. Pray you can find one that works with your 
version of the compiler on your platform, and there are no conflicts with 3rd 
party libraries. No such worries with D compilers.



 And if we go back to java, you can even observe things in a graphic way in
real time
 concurrently to the application running ! Once again, we are not even remotely
 close to anything like this.


It's designed so that you can write one without changing anything in the 
compiler. All you gotta do is override the default one in druntime, which
merely 
aggregates the statistics and prints a report. That report is 90% of what
anyone 
needs. If you want to change the report generator to produce color html output, 
probably 30 min work, feel free.
May 08 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/8/15 3:58 PM, Walter Bright wrote:

 On 5/8/2015 2:51 PM, deadalnix wrote:

 1. unit testing


 The way D runs tests before running the app does not make any sense.


 It works perfectly fine and obviates the need to create a separate test
 harness.



 The way you can't run them for a module without a main makes no sense.


      dmd foo -unittest -main



 The way you end runnign all kind of test with the ones you are
 interested in makes no sense.


     dmd std/path -unittest -main

 runs just the unit tests in std/path. You can run tests in some modules,
 but not others, with:

     dmd -c a b c -unittest
     dmd d e f a.o
     ./d


The issues with unittests are legit, albeit fixable. It's goofy to run 
the program after unittests, and unittests should have names that can be 
introspected, selected etc. I couldn't find much merit with the rest of 
the list. -- Andrei
May 08 2015
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/8/2015 5:25 PM, Andrei Alexandrescu wrote:

 It's goofy to run the program after unittests,


Goofy, maybe, but it makes things simpler. For anyone who is actually bothered 
by it, the fix is a one liner:

   int main(string args)
   {
     version (unittest) exit(0); // <== insert this line
     ...
   }
May 08 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Saturday, 9 May 2015 at 00:24:45 UTC, Andrei Alexandrescu 
wrote:


 The issues with unittests are legit, albeit fixable. It's goofy 
 to run the program after unittests, and unittests should have 
 names that can be introspected, selected etc. I couldn't find 
 much merit with the rest of the list. -- Andrei


Those are really the only ones that I've ever thought made sense, 
and in several cases, the things that folks want are things that 
I very much _don't_ want (e.g. continuing to execute a unittest 
block after an assertion failure). However, while it _is_ a bit 
goofy that the unit tests run just prior to the program running, 
it's easy enough to work around that I've never considered it a 
big deal. Maybe the solution would be to simply make it so that 
main gets replaced when you compile with -unittest rather than 
forcing you to do something like

version(unittest) void main() {}
else void main()
{
     ...
}

It's the lack of unit test names that poses a potentially big 
problem for large projects. But even that shouldn't be hard to 
fix - especially when unittest blocks are already functions with 
names to begin with; it's just that you can't name them yourself. 
But at least their names have their line number in them now. That 
didn't used to be the case, which was even worse - though I'm 
willing to bet that most folks don't realize that the unittest 
block's line number is in its function name.

- Jonathan M Davis
May 10 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-05-10 10:12, Jonathan M Davis wrote:


 Those are really the only ones that I've ever thought made sense, and in
 several cases, the things that folks want are things that I very much
 _don't_ want (e.g. continuing to execute a unittest block after an
 assertion failure).


I don't think most of us want that. What we (I) want is for _other_ unit 
test blocks to run after an assertion failure. I also believe all unit 
test blocks should be completely independent of each other.

-- 
/Jacob Carlborg
May 11 2015
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, 11 May 2015 at 08:18:54 UTC, Jacob Carlborg wrote:

 On 2015-05-10 10:12, Jonathan M Davis wrote:


 Those are really the only ones that I've ever thought made 
 sense, and in
 several cases, the things that folks want are things that I 
 very much
 _don't_ want (e.g. continuing to execute a unittest block 
 after an
 assertion failure).


 I don't think most of us want that. What we (I) want is for 
 _other_ unit test blocks to run after an assertion failure. I 
 also believe all unit test blocks should be completely 
 independent of each other.


Well, for some of the discussions on parallelized unit tests, 
that would be required, and it's certainly good practice in 
general, but there's nothing currently stopping folks from 
writing unittest blocks which rely on what occurred in previous 
unit test blocks, and there are rare circumstances where it makes 
sense.

Hopefully, we can get to the point that druntime is able to run 
tests in parallel and then we can use attributes to mark 
parallelizable unittest blocks to control it.

- Jonathan M Davis
May 11 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/11/15 1:19 AM, Jacob Carlborg wrote:

 On 2015-05-10 10:12, Jonathan M Davis wrote:


 Those are really the only ones that I've ever thought made sense, and in
 several cases, the things that folks want are things that I very much
 _don't_ want (e.g. continuing to execute a unittest block after an
 assertion failure).


 I don't think most of us want that. What we (I) want is for _other_ unit
 test blocks to run after an assertion failure. I also believe all unit
 test blocks should be completely independent of each other.


Yah, that's reasonable. Should be configurable in some easy way. -- Andrei
May 11 2015
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 9 May 2015 at 00:58, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 5/8/2015 2:51 PM, deadalnix wrote:

 1. unit testing


 The way D runs tests before running the app does not make any sense.



 It works perfectly fine and obviates the need to create a separate test
 harness.



 The way you can't run them for a module without a main makes no sense.



     dmd foo -unittest -main



 The way you end runnign all kind of test with the ones you are interested
 in makes no sense.



    dmd std/path -unittest -main

 runs just the unit tests in std/path. You can run tests in some modules, but
 not others, with:

    dmd -c a b c -unittest
    dmd d e f a.o
    ./d



 2. documentation generation



 The fact this is backed into the language the way it is mostly show a lack
 of
 separation of concerns.



 It means it is always there and always the correct version.



 That is a side effect of the fact the frontend is completely monolithic.



 Has nothing to do with how usable a tool is.



 You don't need to bake that into the language when the compiler can feed
 symbol
 information to 3rd party tools.



 D worked with 3rd party doc tools before Ddoc. The result was that maybe 1
 or 2 people ever used such tools. You weren't using D then - the Phobos
 documentation was all of:

 1. nonexistent
 2. wrong
 3. had no correlation with the APIs on the functions at all

 Ddoc fixed all that. It's fine to gripe about this or that, but the results
 are undeniably a seismic improvement for D.



 3. coverage analysis



 I'm not sure how Go and Rust stand on that one, but all mainstream
 languages
 have descent code coverage, with the added bonus that this is very well
 integrated with the rest of the tooling (tolling which is non existent in
 D). I
 would not put this has a string point of D. Not bad either, but
 definitively
 what you'd expect from any serious language.



 Try using gcov without going back to consult the manuals on it. Even if you
 have it installed. Coverage analyzers in other languages that I checked all
 required finding and installing some extra package, then trying to figure
 out how to hook it in.



 Last but not least, things like:
 if (foo && bar) ...;

 Contains 2 branches. The output we have to not provide data about this,
 which
 makes the coverage infos lacking in some regard.



 Check before assuming -cov does it wrong. You'll find it counts the branches
 separately. It does sum them for the line count, but writing it as:

    if (foo &&
        bar)
         ....

 you'll get two counts. What I am disappointed in is the repeated default
 assumption, without bothering to check, that D's tools are guilty until
 proven innocent.



 In java for instance, I could run tests (and not the whole program with
 test at
 startup) and get all the coverage infos directly in my editor with colors
 and
 stuff, include things like short circuit for boolean operators, which we
 don't
 have. We are miles (kilometers damn it !) away from this level of support.



 Here's a slice of a D coverage report:


        |static if (allSatisfy!(hasMobileElements, R))
        |{
        |    RvalueElementType moveAt(size_t index)
        |    {
       6|        foreach (i, Range; R)
        |        {
        |            static if (isInfinite!(Range))
        |            {
 0000000|                return .moveAt(source[i], index);
        |            }
        |            else
        |            {
       3|                immutable length = source[i].length;
       5|                if (index < length) return .moveAt(source[i],
 index);
       1|                    index -= length;
        |            }
        |        }
 0000000|        assert(false);
        |    }
        |}
 std\range\package.d is 91% covered

 It's not in color, I concede that. Saying this report is "miles behind" is
 ludicrous, besides the incorrect statement that short circuits are not
 supported.


For the sake of argument (and genuine interest).  I'd like to see a
comparison of DMD coverage versus GDC coverage reporting.  ie: Does
DMD pick up anything GDC doesn't?  Are there areas where GDC is more
clearer?

For the latter question though, because gcov has lots of external
tooling, the latter may be an unfair bias towards gcov.

For example, using site linked at [1], I can build and run the
druntime/phobos unittests using --coverage in my DFLAGS and get
instant results with:


  $ lcov --capture --directory libphobos --output-file libphobos-cov.info


  $ genhtml libphobos-cov.info --output-directory coverage

Then browse it once uploaded.

  http://coverage.dgnu.org

Regards
Iain.

[1]: http://ltp.sourceforge.net/coverage/lcov.php
May 09 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2015 12:30 PM, Iain Buclaw via Digitalmars-d wrote:

 For the sake of argument (and genuine interest).  I'd like to see a
 comparison of DMD coverage versus GDC coverage reporting.  ie: Does
 DMD pick up anything GDC doesn't?  Are there areas where GDC is more
 clearer?


Color reports, html reports, all that is 1%. The largest problem we face with 
dmd -cov is simply getting people to use it as a matter of course. I know that 
it is not being used pervasively because when I run Phobos unit tests with
-cov, 
large swaths of code are not tested.

dmd -cov=nn will also cause the generated executable to exit with an error if 
the coverage is below nn%. I'd like this to be part of the the autotester so 
that backsliding can be detected automatically, but that's not on dmd, it's on 
how the test suite is put together and scripted.
May 09 2015
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 05/08/2015 06:58 PM, Walter Bright wrote:

 On 5/8/2015 2:51 PM, deadalnix wrote:

 The way you end runnign all kind of test with the ones you are
 interested in makes no sense.


     dmd std/path -unittest -main

 runs just the unit tests in std/path. You can run tests in some modules,
 but not others, with:

     dmd -c a b c -unittest
     dmd d e f a.o
     ./d


That breaks most build systems, including rdmd.
May 09 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2015 1:57 PM, Nick Sabalausky wrote:

 On 05/08/2015 06:58 PM, Walter Bright wrote:

 On 5/8/2015 2:51 PM, deadalnix wrote:

 The way you end runnign all kind of test with the ones you are
 interested in makes no sense.


     dmd std/path -unittest -main

 runs just the unit tests in std/path. You can run tests in some modules,
 but not others, with:

     dmd -c a b c -unittest
     dmd d e f a.o
     ./d


 That breaks most build systems, including rdmd.



Build systems cannot handle giving different compile flags to different files? 
Back to using 'make' :-)
May 09 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 9 May 2015 at 22:44:28 UTC, Walter Bright wrote:

 Build systems cannot handle giving different compile flags to 
 different files? Back to using 'make' :-)


Compiling different object files with different version flags is 
current illegal in D and may result in linking errors.
May 09 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2015 4:10 PM, Dicebot wrote:

 On Saturday, 9 May 2015 at 22:44:28 UTC, Walter Bright wrote:

 Build systems cannot handle giving different compile flags to different files?
 Back to using 'make' :-)


 Compiling different object files with different version flags is current
illegal
 in D and may result in linking errors.


That's true with many flags for C and C++ compilers, too. But it doesn't stop 
anyone from routinely using different flags for different source files.

(dmd's makefiles, for example)
May 09 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 9 May 2015 at 23:36:03 UTC, Walter Bright wrote:

 On 5/9/2015 4:10 PM, Dicebot wrote:

 On Saturday, 9 May 2015 at 22:44:28 UTC, Walter Bright wrote:

 Build systems cannot handle giving different compile flags to 
 different files?
 Back to using 'make' :-)


 Compiling different object files with different version flags 
 is current illegal
 in D and may result in linking errors.


 That's true with many flags for C and C++ compilers, too. But 
 it doesn't stop anyone from routinely using different flags for 
 different source files.

 (dmd's makefiles, for example)


Until it breaks. And it breaks pretty fast with version(unittest) 
if you start using it as a common idiom.
May 09 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2015 5:26 PM, Dicebot wrote:

 Until it breaks. And it breaks pretty fast with version(unittest) if you start
 using it as a common idiom.


It's no harder to get right than -DWHATEVER in C and C++.

Any system that has separate compilation and conditional compilation means 
taking a bit of care when mixing them.
May 09 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 10 May 2015 at 01:04:31 UTC, Walter Bright wrote:

 On 5/9/2015 5:26 PM, Dicebot wrote:

 Until it breaks. And it breaks pretty fast with 
 version(unittest) if you start
 using it as a common idiom.


 It's no harder to get right than -DWHATEVER in C and C++.

 Any system that has separate compilation and conditional 
 compilation means taking a bit of care when mixing them.


https://issues.dlang.org/show_bug.cgi?id=13454
May 09 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2015 6:25 PM, Dicebot wrote:

 https://issues.dlang.org/show_bug.cgi?id=13454


Thanks for the link. Thought it best to reply there.
May 09 2015
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, May 09, 2015 at 03:44:40PM -0700, Walter Bright via Digitalmars-d wrote:

 On 5/9/2015 1:57 PM, Nick Sabalausky wrote:

On 05/08/2015 06:58 PM, Walter Bright wrote:

On 5/8/2015 2:51 PM, deadalnix wrote:

The way you end runnign all kind of test with the ones you are
interested in makes no sense.


    dmd std/path -unittest -main

runs just the unit tests in std/path. You can run tests in some
modules, but not others, with:

    dmd -c a b c -unittest
    dmd d e f a.o
    ./d


That breaks most build systems, including rdmd.


 
 
 Build systems cannot handle giving different compile flags to
 different files? Back to using 'make' :-)


Of course it can. I have done it before, it's not that hard. (And build
systems that don't support that, suck. :-P)

The more enlightening question is, why is it a bad idea to give
different compile flags to different files? And the answer is that it's
not a recommended setup, as you may cause subtle breakage between
modules that may lead to hard-to-find heisenbugs that only show up at
runtime but don't exist in code.

Contrived example:

	module mymod;
	version(UseFloat) float x;
	else int x;

	module main;
	import mymod;
	void main() {
		x = 0;
		writeln(x);
	}

Compile commands:

	dmd -c mymod.d

	dmd -ofprog main.o mymod.o


T

-- 
A linguistics professor was lecturing to his class one day. "In English," he
said, "A double negative forms a positive. In some languages, though, such as
Russian, a double negative is still a negative. However, there is no language
wherein a double positive can form a negative." A voice from the back of the
room piped up, "Yeah, yeah."
May 09 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
Contrived example:

	// mymod.h
         #ifdef UseFloat
	extern float x;
	#else
         extern int x;
         #endif

	// main.c
         #include <stdio.h>
	#include "mymod.h"
	void main() {
		x = 0;
		printf("%d\n", x);
	}

Compile commands:

	gcc -c mymod.c

	gcc main.o mymod.o



The thing is, every day I compile some modules with -unittest, and some
without, 
and link together together. Even if the ones without -unittest are the linked
in 
Phobos modules. The autotester does it all day every day, too.

If this didn't work, D's unit tests indeed would be rather useless.
May 09 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 8 May 2015 at 22:57:54 UTC, Walter Bright wrote:

 It works perfectly fine and obviates the need to create a 
 separate test harness.


As long as you are doing trivial toy programs, that is perfect.


 Try using gcov without going back to consult the manuals on it. 
 Even if you have it installed. Coverage analyzers in other 
 languages that I checked all required finding and installing 
 some extra package, then trying to figure out how to hook it in.


As mentioned elsewhere one want to compared itself to the guy in 
town, not the drunk hobbo.


 Last but not least, things like:
 if (foo && bar) ...;

 Contains 2 branches. The output we have to not provide data 
 about this, which
 makes the coverage infos lacking in some regard.


 Check before assuming -cov does it wrong. You'll find it counts 
 the branches separately. It does sum them for the line count, 
 but writing it as:

    if (foo &&
        bar)
         ....

 you'll get two counts. What I am disappointed in is the 
 repeated default assumption, without bothering to check, that 
 D's tools are guilty until proven innocent.


My bad. It is still clowny that I have to format my code in a 
particular way to get that result. Not formatting my code that 
way, I never noticed that the result even existed in the first 
place.

But still, that is clowny and confirms the general impression 
that these tools are bad.

See, there are iPhone and nokia phones. They do the same thing: 
they load web pages, they do phone calls and sms, they runs 
various apps and so on. An iPhone more than twice the price of a 
nokia lumia. Still, people are willing to wait in line to buy the 
new iPhone while nokia is going bankrupt. Why is that ? Because 
in one case, the damn thing is thought through to the most 
insignificant details once the other works and that's good.

You can do this if you format you code in some bizarre way is a 
bad excuse and nothing else.


 In java for instance, I could run tests (and not the whole 
 program with test at
 startup) and get all the coverage infos directly in my editor 
 with colors and
 stuff, include things like short circuit for boolean 
 operators, which we don't
 have. We are miles (kilometers damn it !) away from this level 
 of support.


 Here's a slice of a D coverage report:


        |static if (allSatisfy!(hasMobileElements, R))
        |{
        |    RvalueElementType moveAt(size_t index)
        |    {
       6|        foreach (i, Range; R)
        |        {
        |            static if (isInfinite!(Range))
        |            {
 0000000|                return .moveAt(source[i], index);
        |            }
        |            else
        |            {
       3|                immutable length = source[i].length;
       5|                if (index < length) return 
 .moveAt(source[i], index);
       1|                    index -= length;
        |            }
        |        }
 0000000|        assert(false);
        |    }
        |}
 std\range\package.d is 91% covered

 It's not in color, I concede that. Saying this report is "miles 
 behind" is ludicrous, besides the incorrect statement that 
 short circuits are not supported.


Color are beside the point. That is a good report. That is still 
miles behind what you can have in java for instance.

I can't have the coverage per test case, to know what test is 
testing what for instance (which is arguably mostly due to how 
tests are ran in the first place). It does give me information 
depending on the formatting of my code. These may not seems like 
important things, but that is what makes the difference.


 4. profiler


 Same things, this is a standard tool nowaday for any language 
 worth considering.
 In fact, even if we had no specific support in D for it, C/C++ 
 tooling could
 probably do it for us to some extent.


 Yah, I know about gprof. Try it (with a C or C++ program), 
 without spending time with the manuals. Here's the manual for D:

    dmd -profile foo


1/ I usually use callgrind based tools rather than gcov, and then 
I can explore the result with something like KCacheGrind which 
can show me the informations in all kind of forms.

http://edinburghhacklab.com/wp-content/uploads/2012/04/kcachegrind.png

Not only this is more convenient to explore the data, but I get 
the same tool to work with PHP, C++ or whatever else.

On the other hand, I have something like:
$ cat trace.log
------------------
	    1	main
_Dmain	1	45	45
------------------
main	0	0	0
	    1	_Dmain

======== Timer Is 3579545 Ticks/Sec, Times are in Microsecs 
========

   Num          Tree        Func        Per
   Calls        Time        Time        Call

       1          12          12          12     _Dmain
       1           0           0           0     main

For reference, the format used is named callgrind and many tools 
can manipulate it: http://valgrind.org/docs/manual/cl-format.html

2/ Tested on SDC's test runner, it makes the test runner 
segfault. It is not even a complicated program. That is once 
against the nokia vs apple thing.


 5. and as of last week, a memory usage profiler


 Good memory allocator like tcmalloc and/or jemalloc have 
 detailed output.


 They don't come with C or C++. Pray you can find one that works 
 with your version of the compiler on your platform, and there 
 are no conflicts with 3rd party libraries. No such worries with 
 D compilers.


I can use both tcmalloc and jemalloc on WAY MORE plateforms that 
D supports.


 And if we go back to java, you can even observe things in a 
 graphic way in real time
 concurrently to the application running ! Once again, we are 
 not even remotely
 close to anything like this.


 It's designed so that you can write one without changing 
 anything in the compiler. All you gotta do is override the 
 default one in druntime, which merely aggregates the statistics 
 and prints a report. That report is 90% of what anyone needs. 
 If you want to change the report generator to produce color 
 html output, probably 30 min work, feel free.


I know it is doable. Java does it. But D does not. I'm discussing 
what we have right now, not what we could hypothetically have if 
you, me, and others had infinite time.

As D does not, it can't be pointed as a strong asset of D.
May 09 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2015 8:56 PM, deadalnix wrote:

 As long as you are doing trivial toy programs, that is perfect.


The compiler is not a trivial toy program - it's how I made DMC++ still the 
fastest C++ compiler available. I also used it on dmd. dmd being very fast is 
not an accident.



 My bad. It is still clowny that I have to format my code in a particular way to
 get that result. Not formatting my code that way, I never noticed that the
 result even existed in the first place.


Consider:

  5| foo();
  7| if (a && b)

If you were examining the line counts, wouldn't you notice something like that? 
It's pretty obvious that a is executed 5 times and b twice. I use this tool a 
lot. I get what's needed out of them, while keeping the report as a simple
printout.



 I can't have the coverage per test case, to know what test is testing what for
 instance (which is arguably mostly due to how tests are ran in the first
place).
 It does give me information depending on the formatting of my code. These may
 not seems like important things, but that is what makes the difference.


I saw the report in the picture you linked to. It looks nice. How will it make 
me more productive?



 On the other hand, I have something like:
 $ cat trace.log
 ------------------
          1    main
 _Dmain    1    45    45
 ------------------
 main    0    0    0
          1    _Dmain

 ======== Timer Is 3579545 Ticks/Sec, Times are in Microsecs ========

    Num          Tree        Func        Per
    Calls        Time        Time        Call

        1          12          12          12     _Dmain
        1           0           0           0     main


All that's needed to make DMC++ still the fastest C++ compiler. (The dmd 
profiler is the same as the DMC++ one, but fixed for multithreading.) It tracks 
who are the top time users, and how they get called in a simple format.

I understand that those colorful graphical displays look pretty, and are fun to 
browse around on. What I don't understand is how that translates into a 
programmer being more productive with those results, let alone miles more 
productive.



 For reference, the format used is named callgrind and many tools can manipulate
 it: http://valgrind.org/docs/manual/cl-format.html


Thanks for the link, I've never heard of that before. Switching to it, however, 
now means that the poor user has to download and install more tools to get 
results, and the process of using it is no longer one step.

[If cl-format is really miles better, why not submit a PR to have the dmd
report 
generator output that?]

One output from -profile you might not have noticed is a .def file. This sets 
the link order for functions, so that functions that are strongly connected at 
runtime are located adjacent to each other. Makes for much better virtual
paging 
and cache performance. It currently only works for Optlink, because nobody
cares 
about it.



 I can use both tcmalloc and jemalloc on WAY MORE plateforms that D supports.


My point is you are guaranteed to have the D tools with every D compiler, 
regardless of what platform it is on. And of course you can use tcmalloc and 
jemalloc with D, if you want to.



 Tested on SDC's test runner, it makes the test runner segfault.


The only known cause of -profile seg faulting was running it on multithreaded 
programs. That's been corrected. If this is something else, without a bugzilla 
report, nothing will happen. And that's true with every language.
May 09 2015
prev sibling next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Friday, 8 May 2015 at 21:51:24 UTC, deadalnix wrote:

 ...
 Same things, this is a standard tool nowaday for any language 
 worth considering. In fact, even if we had no specific support 
 in D for it, C/C++ tooling could probably do it for us to some 
 extent.


On this note, I think D is missing out on a lot of opportunities 
provided by the LLVM infrastructure. A lot of neat things are 
built ontop of LLVM now - for example, nim and rust are taking 
advantage of LLVM's emscripten/pnacl support to write web 
programs, and Rust is being used for GPU programming by making 
use of LLVM's PTX target.

On the D side, AFAIK Calypso is only possible because of LLVM - 
but to be fair I haven't really looked at it.
May 08 2015
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, May 08, 2015 at 09:51:23PM +0000, deadalnix via Digitalmars-d wrote:
[...]

4. profiler


 
 Same things, this is a standard tool nowaday for any language worth
 considering. In fact, even if we had no specific support in D for it,
 C/C++ tooling could probably do it for us to some extent.


[...]

I use dmd with gprof with not-bad results. It's not perfect, but at
least I can get some useful info out of it.

The built-in dmd profiler is unfortunately unusable for me because its
function call counters wrap around far too early (IIRC they use 16-bit
counters or something like that), whereas the test cases I need to
optimize for are the long-running, steady state test cases in which
millions or billions of function calls are made.

Will this ever be improved?


T

-- 
Why can't you just be a nonconformist like everyone else? -- YHL
May 08 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/8/2015 10:09 PM, H. S. Teoh via Digitalmars-d wrote:

 The built-in dmd profiler is unfortunately unusable for me because its
 function call counters wrap around far too early (IIRC they use 16-bit
 counters or something like that),


32 bit counters

https://github.com/D-Programming-Language/druntime/blob/master/src/rt/trace.d#L38


 whereas the test cases I need to
 optimize for are the long-running, steady state test cases in which
 millions or billions of function calls are made.

 Will this ever be improved?


     if (bugzilla report submitted || developers are mind readers)
     {
	maybe it'll get fixed!
     }
     else
     {
         nobody knows there's a problem
     }

Feel free to submit a PR to make 'count' a ulong.
May 08 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, May 08, 2015 at 10:36:28PM -0700, Walter Bright via Digitalmars-d wrote:

 On 5/8/2015 10:09 PM, H. S. Teoh via Digitalmars-d wrote:

The built-in dmd profiler is unfortunately unusable for me because
its function call counters wrap around far too early (IIRC they use
16-bit counters or something like that),


 
 32 bit counters
 
 https://github.com/D-Programming-Language/druntime/blob/master/src/rt/trace.d#L38
 

whereas the test cases I need to
optimize for are the long-running, steady state test cases in which
millions or billions of function calls are made.

Will this ever be improved?


 
     if (bugzilla report submitted || developers are mind readers)
     {
 	maybe it'll get fixed!
     }
     else
     {
         nobody knows there's a problem
     }
 
 Feel free to submit a PR to make 'count' a ulong.


https://issues.dlang.org/show_bug.cgi?id=14565

I also just realized that on Posix the profiling code apparently relies
on the rdtsc instruction, which counts CPU cycles in a 64-bit counter --
given the high frequencies of modern CPUs, moderately long-running
CPU-intensive processes easily overflow this counter, leading to
wrapped-around timing values and completely garbled output.

gprof, for all of its flaws, does not suffer from this problem.


T

-- 
Curiosity kills the cat. Moral: don't be the cat.
May 09 2015
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/10/2015 07:39 AM, H. S. Teoh via Digitalmars-d wrote:

 I also just realized that on Posix the profiling code apparently relies
 on the rdtsc instruction, which counts CPU cycles in a 64-bit counter --
 given the high frequencies of modern CPUs, moderately long-running
 CPU-intensive processes easily overflow this counter, leading to
 wrapped-around timing values and completely garbled output.

 gprof, for all of its flaws, does not suffer from this problem.


http://www.wolframalpha.com/input/?i=2^64%2F%289+GHz%29

What am I missing?
May 10 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 10 May 2015 at 12:54:02 UTC, Timon Gehr wrote:

 On 05/10/2015 07:39 AM, H. S. Teoh via Digitalmars-d wrote:

 I also just realized that on Posix the profiling code 
 apparently relies
 on the rdtsc instruction, which counts CPU cycles in a 64-bit 
 counter --
 given the high frequencies of modern CPUs, moderately 
 long-running
 CPU-intensive processes easily overflow this counter, leading 
 to
 wrapped-around timing values and completely garbled output.

 gprof, for all of its flaws, does not suffer from this problem.


 http://www.wolframalpha.com/input/?i=2^64%2F%289+GHz%29

 What am I missing?


http://www.wolframalpha.com/input/?i=2^32%2F%289+GHz%29

It doesn't look at good that way, especially if you have some 
tight loops.
May 10 2015
prev sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Saturday, 9 May 2015 at 05:12:28 UTC, H. S. Teoh wrote:

 On Fri, May 08, 2015 at 09:51:23PM +0000, deadalnix via 
 Digitalmars-d wrote:
 [...]

4. profiler


 
 Same things, this is a standard tool nowaday for any language 
 worth
 considering. In fact, even if we had no specific support in D 
 for it,
 C/C++ tooling could probably do it for us to some extent.


 [...]

 I use dmd with gprof with not-bad results. It's not perfect, 
 but at
 least I can get some useful info out of it.

 The built-in dmd profiler is unfortunately unusable for me 
 because its
 function call counters wrap around far too early (IIRC they use 
 16-bit
 counters or something like that), whereas the test cases I need 
 to
 optimize for are the long-running, steady state test cases in 
 which
 millions or billions of function calls are made.

 Will this ever be improved?


 T


have you tried oprofile? It's embarrassingly simple to use, 
especially compared to perf. oprofile used to be much worse though
May 09 2015
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 05/07/2015 08:16 AM, d user wrote:

 Go comes with a package manager,


Dub is slated to become packaged with DMD.


 a linter,


-wi


 a static analysis tool,


Normal D language semantics ;)


 a formatter.


Granted, not built-in, but a pretty minor thing IMO.
May 08 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/8/2015 7:24 AM, Nick Sabalausky wrote:

 a formatter.


 Granted, not built-in, but a pretty minor thing IMO.


I use detab and tolf as part of my checkin script :-)
May 08 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-05-06 20:26, Brad Anderson wrote:

 https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx

 I'm sharing this specifically so we can have an unproductive flamewar
 about whether breaking changes in D are sometimes worth it or if they
 are holding D back from mass adoption :).


I would say that the difference with the MS C++ compiler compared to D 
is that there's already an existing C++ standard that MS is expected to 
follow. Most of the breaking changes seem to be related to make MS's 
implementation of C++ more compatible with the C++ standard.

Compared to D where not real standard exists. There's a least three 
separate things trying to define what D is. The D spec on dlang.org, the 
compiler (DMD) and TDPL. In most cases when there's a disagreement the 
compiler wins.

-- 
/Jacob Carlborg
May 07 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
Just for the record: upgrading compilers never worked for me at 
least for C. Yesterday I found that whatever clang I had doesn't 
work so I upgraded to the latest version, which can't compile 
mingw headers. Bummer.
Jun 06 2015