On 9 May 2015 at 00:58, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 5/8/2015 2:51 PM, deadalnix wrote:
>>>
>>> 1. unit testing
>>
>> The way D runs tests before running the app does not make any sense.
>
>
> It works perfectly fine and obviates the need to create a separate test harness.
>
>
>> The way you can't run them for a module without a main makes no sense.
>
>
>     dmd foo -unittest -main
>
>
>> The way you end runnign all kind of test with the ones you are interested in makes no sense.
>
>
>    dmd std/path -unittest -main
>
> runs just the unit tests in std/path. You can run tests in some modules, but not others, with:
>
>    dmd -c a b c -unittest
>    dmd d e f a.o
>    ./d
>
>
>>> 2. documentation generation
>>
>>
>> The fact this is backed into the language the way it is mostly show a lack
>> of
>> separation of concerns.
>
>
> It means it is always there and always the correct version.
>
>
>> That is a side effect of the fact the frontend is completely monolithic.
>
>
> Has nothing to do with how usable a tool is.
>
>
>> You don't need to bake that into the language when the compiler can feed
>> symbol
>> information to 3rd party tools.
>
>
> D worked with 3rd party doc tools before Ddoc. The result was that maybe 1 or 2 people ever used such tools. You weren't using D then - the Phobos documentation was all of:
>
> 1. nonexistent
> 2. wrong
> 3. had no correlation with the APIs on the functions at all
>
> Ddoc fixed all that. It's fine to gripe about this or that, but the results are undeniably a seismic improvement for D.
>
>
>>> 3. coverage analysis
>>
>>
>> I'm not sure how Go and Rust stand on that one, but all mainstream
>> languages
>> have descent code coverage, with the added bonus that this is very well
>> integrated with the rest of the tooling (tolling which is non existent in
>> D). I
>> would not put this has a string point of D. Not bad either, but
>> definitively
>> what you'd expect from any serious language.
>
>
> Try using gcov without going back to consult the manuals on it. Even if you have it installed. Coverage analyzers in other languages that I checked all required finding and installing some extra package, then trying to figure out how to hook it in.
>
>
>> Last but not least, things like:
>> if (foo && bar) ...;
>>
>> Contains 2 branches. The output we have to not provide data about this,
>> which
>> makes the coverage infos lacking in some regard.
>
>
> Check before assuming -cov does it wrong. You'll find it counts the branches separately. It does sum them for the line count, but writing it as:
>
>    if (foo &&
>        bar)
>         ....
>
> you'll get two counts. What I am disappointed in is the repeated default assumption, without bothering to check, that D's tools are guilty until proven innocent.
>
>
>> In java for instance, I could run tests (and not the whole program with
>> test at
>> startup) and get all the coverage infos directly in my editor with colors
>> and
>> stuff, include things like short circuit for boolean operators, which we
>> don't
>> have. We are miles (kilometers damn it !) away from this level of support.
>
>
> Here's a slice of a D coverage report:
>
>
>        |static if (allSatisfy!(hasMobileElements, R))
>        |{
>        |    RvalueElementType moveAt(size_t index)
>        |    {
>       6|        foreach (i, Range; R)
>        |        {
>        |            static if (isInfinite!(Range))
>        |            {
> 0000000|                return .moveAt(source[i], index);
>        |            }
>        |            else
>        |            {
>       3|                immutable length = source[i].length;
>       5|                if (index < length) return .moveAt(source[i],
> index);
>       1|                    index -= length;
>        |            }
>        |        }
> 0000000|        assert(false);
>        |    }
>        |}
> std\range\package.d is 91% covered
>
> It's not in color, I concede that. Saying this report is "miles behind" is ludicrous, besides the incorrect statement that short circuits are not supported.
>

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

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

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

  # 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

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

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.

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.

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' :-)

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

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.

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

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)

Contrived example:

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

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

Compile commands:

	gcc -c mymod.c
	gcc -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.