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