Breaking changes in Visual C++ 2015
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 :).
Re: Breaking changes in Visual C++ 2015
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).
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
On 7 May 2015 at 14:16, d user via Digitalmars-d 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...
Re: Breaking changes in Visual C++ 2015
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...
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
On Thu, 07 May 2015 12:16:17 +, d user wrote: > If you want D to stay unpopular, keep moving > towards Haskell with braces. i'll go with "Haskell with braces". signature.asc Description: PGP signature
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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?
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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…
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
On 5/8/2015 1:16 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " 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.
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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?= " 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).
Re: Breaking changes in Visual C++ 2015
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?= " 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.
Re: Breaking changes in Visual C++ 2015
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?= " 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.
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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!
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
Thanks for the explanation.
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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. --
Re: Breaking changes in Visual C++ 2015
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 :-)
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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))
|{
000|return .moveAt(source[i], index);
|}
|else
|{
3|immutable length = source[i].length;
5|if (index < length) return .moveAt(source[i], index);
1|index -= length;
|}
|}
000|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 col
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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
...
}
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
On Fri, May 08, 2015 at 09:51:23PM +, 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
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
On Saturday, 9 May 2015 at 05:12:28 UTC, H. S. Teoh wrote: On Fri, May 08, 2015 at 09:51:23PM +, 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
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
On 9 May 2015 at 00:58, Walter Bright via Digitalmars-d
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))
>|{
> 000|return .moveAt(source[i], index);
>|}
>|else
>|{
> 3|immutable length = source[i].length;
> 5|if (index < length) return .moveAt(source[i],
> index);
> 1|index -= length;
>|}
>|}
> 000|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:
# Capture all information
$ lcov --capture --directory libphobos --output-file libphobos-cov.info
# Generate instant web pages
$ 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
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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' :-)
Re: Breaking changes in Visual C++ 2015
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).
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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 -c -version=UseFloat main.d # <-- oops
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."
Re: Breaking changes in Visual C++ 2015
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)
Re: Breaking changes in Visual C++ 2015
Contrived example:
// mymod.h
#ifdef UseFloat
extern float x;
#else
extern int x;
#endif
// main.c
#include
#include "mymod.h"
void main() {
x = 0;
printf("%d\n", x);
}
Compile commands:
gcc -c mymod.c
gcc -c -DUseFloat main.c# <-- oops
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.
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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))
|{
000|return .moveAt(source[i], index);
|}
|else
|{
3|immutable length = source[i].length;
5|if (index < length) return
.moveAt(source[i], index);
1|index -= length;
|}
|}
000|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
--
main0 0 0
1 _Dmain
Timer Is 3579545 Ticks/Sec, Times are in Microsecs
Num TreeFuncPer
CallsTimeTimeCall
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
Re: Breaking changes in Visual C++ 2015
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 :)
Re: Breaking changes in Visual C++ 2015
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 -- 1main _Dmain14545 -- main000 1_Dmain Timer Is 3579545 Ticks/Sec, Times are in Microsecs Num TreeFuncPer CallsTimeTimeCall 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.
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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?
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
Am Thu, 14 May 2015 15:00:32 + schrieb "Victor" : > 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.
Re: Breaking changes in Visual C++ 2015
On 14 May 2015 at 17:40, Johannes Pfau via Digitalmars-d wrote: > Am Thu, 14 May 2015 15:00:32 + > schrieb "Victor" : > >> 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.
Re: Breaking changes in Visual C++ 2015
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
Re: Breaking changes in Visual C++ 2015
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.
Re: Breaking changes in Visual C++ 2015
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.
