What would be a simple way to count the "effective" lines in a module, i.e. excluding ddoc comments and unittests? Having a tool for that in tools/ would be neat. -- Andrei

Try dscanner --sloc although IMO --tokenCount should be the most relevant
metric (only caveat is mixin strings with which one could cheat to make
token count smaller).
TokenCount formatting invariant

On Feb 25, 2017 11:36 AM, "Andrei Alexandrescu via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:

What would be a simple way to count the "effective" lines in a module, i.e. excluding ddoc comments and unittests? Having a tool for that in tools/ would be neat. -- Andrei

On 2/25/17 2:55 PM, Timothee Cour via Digitalmars-d wrote:
> Try dscanner --sloc although IMO --tokenCount should be the most
> relevant metric (only caveat is mixin strings with which one could cheat
> to make token count smaller).

Thanks, got that working with ease. The operation of dub has gotten quite a bit smoother, props to Sönke!

One thing that I found surprising is the chatter that seems impossible to mute. Here's a session:

$ dub run dscanner -- --sloc ../phobos/std/traits.d
Building package dscanner in /Users/andrei/.dub/packages/dscanner-0.4.0/
Target libdparse 0.7.0 is up to date. Use --force to rebuild.
Target emsi_containers 0.5.3 is up to date. Use --force to rebuild.
Target dsymbol 0.2.0 is up to date. Use --force to rebuild.
Target inifiled 0.0.6 is up to date. Use --force to rebuild.
Target dscanner 0.4.0 is up to date. Use --force to rebuild.
Running ../../.dub/packages/dscanner-0.4.0/dscanner --sloc ../phobos/std/traits.d
../phobos/std/traits.d:	3747
total:	3747

I might be missing something, so bear with me. My current understanding is:

* The usual way to run stuff gotten via dub is with "dub run", so that people don't need to deal with version directories and complex paths such as ~/.dub/packages/dscanner-0.4.0/dscanner.

* There is no easy way to get rid of the chatteroo prefacing the actual output from the application. One possibility I imagine is a rather gnarly sed script that prints nothing until it detects '^Running ', and then starts printing everything.

* There is even no --quiet option (https://code.dlang.org/docs/commandline#run) with run that instructs dub to not inform about things being up to date.

Are these correct? In that case, dub runs afoul of the Rule of Silence: the command "dub run xyz" should only output whatever xyz outputs if dub takes no actual additional build steps. By the RoS, there might be a --verbose flag with dmd run that prints the above.

What am I missing?


Thanks,

Andrei

On Sunday, 26 February 2017 at 05:50:32 UTC, Andrei Alexandrescu wrote:
> I might be missing something, so bear with me. My current understanding is:
>
> * The usual way to run stuff gotten via dub is with "dub run", so that people don't need to deal with version directories and complex paths such as ~/.dub/packages/dscanner-0.4.0/dscanner.
>
> * There is no easy way to get rid of the chatteroo prefacing the actual output from the application. One possibility I imagine is a rather gnarly sed script that prints nothing until it detects '^Running ', and then starts printing everything.
>
> * There is even no --quiet option (https://code.dlang.org/docs/commandline#run) with run that instructs dub to not inform about things being up to date.
>
> Are these correct? In that case, dub runs afoul of the Rule of Silence: the command "dub run xyz" should only output whatever xyz outputs if dub takes no actual additional build steps. By the RoS, there might be a --verbose flag with dmd run that prints the above.
>
> What am I missing?

I think that the DUB issue list [0]
has grown immensely over the last two years as it's nearly only Sönke maintaining - it's not like he doesn't maintain ddox [1], Vibe.d [2], eventcore [3] (an abstraction for event loop libraries that hopefully one day finds its way to Phobos), std.data.json [4] (an kickass Json library), diet-ng [5] (the template system used by Vibe.d), tagged-algebraic [6], the DUB registry [7] and so on.
Moreover, Dub's issue list [0] is filled with real bugs and important feature requests (git support, C/C++ integration like Rust, ...).

That been said DUB is a build tool and it's good to be in verbose in case of errors and there's `-q` which you can use as expected, e.g:

> dub run dscanner -q -- --sloc .

It's documented in the beginning of the document you linked under "general options".
When it's used in the `--single` file mode (aka #!/usr/bin/env dub) it's quiet by default.

[0] https://github.com/dlang/dub/issues
[1] https://github.com/rejectedsoftware/ddox
[2] https://github.com/rejectedsoftware/vibe.d
[3] https://github.com/vibe-d/eventcore
[4] https://github.com/s-ludwig/std_data_json
[5] https://github.com/rejectedsoftware/diet-ng
[6] https://github.com/s-ludwig/taggedalgebraic
[7] https://github.com/dlang/dub-registry

On Sunday, 26 February 2017 at 05:50:32 UTC, Andrei Alexandrescu wrote:
> What am I missing?

I installed dscanner from my package manager (homebrew), so I don't get any of the extra dub noise at all.

On Saturday, 25 February 2017 at 19:31:06 UTC, Andrei Alexandrescu wrote:
> What would be a simple way to count the "effective" lines in a module, i.e. excluding ddoc comments and unittests? Having a tool for that in tools/ would be neat. -- Andrei

Fun fact I found out using this thread: 57.4% of the lines in Phobos are non-code lines.

On 2017-02-26 06:50, Andrei Alexandrescu wrote:
> On 2/25/17 2:55 PM, Timothee Cour via Digitalmars-d wrote:
>> Try dscanner --sloc although IMO --tokenCount should be the most
>> relevant metric (only caveat is mixin strings with which one could cheat
>> to make token count smaller).
>
> Thanks, got that working with ease. The operation of dub has gotten
> quite a bit smoother, props to Sönke!
>
> One thing that I found surprising is the chatter that seems impossible
> to mute. Here's a session:
>
> $ dub run dscanner -- --sloc ../phobos/std/traits.d
> Building package dscanner in /Users/andrei/.dub/packages/dscanner-0.4.0/
> Target libdparse 0.7.0 is up to date. Use --force to rebuild.
> Target emsi_containers 0.5.3 is up to date. Use --force to rebuild.
> Target dsymbol 0.2.0 is up to date. Use --force to rebuild.
> Target inifiled 0.0.6 is up to date. Use --force to rebuild.
> Target dscanner 0.4.0 is up to date. Use --force to rebuild.
> Running ../../.dub/packages/dscanner-0.4.0/dscanner --sloc
> ../phobos/std/traits.d
> ../phobos/std/traits.d:    3747
> total:    3747
>
> I might be missing something, so bear with me. My current understanding is:
>
> * The usual way to run stuff gotten via dub is with "dub run", so that
> people don't need to deal with version directories and complex paths
> such as ~/.dub/packages/dscanner-0.4.0/dscanner.
>
> * There is no easy way to get rid of the chatteroo prefacing the actual
> output from the application. One possibility I imagine is a rather
> gnarly sed script that prints nothing until it detects '^Running ', and
> then starts printing everything.
>
> * There is even no --quiet option
> (https://code.dlang.org/docs/commandline#run) with run that instructs
> dub to not inform about things being up to date.
>
> Are these correct? In that case, dub runs afoul of the Rule of Silence:
> the command "dub run xyz" should only output whatever xyz outputs if dub
> takes no actual additional build steps. By the RoS, there might be a
> --verbose flag with dmd run that prints the above.
>
> What am I missing?

Dub is not intended for end user installation of programs/tools. The system package manager should be used for that.

-- 
/Jacob Carlborg

On 02/26/2017 02:31 AM, Jack Stouffer wrote:
> On Saturday, 25 February 2017 at 19:31:06 UTC, Andrei Alexandrescu wrote:
>> What would be a simple way to count the "effective" lines in a module,
>> i.e. excluding ddoc comments and unittests? Having a tool for that in
>> tools/ would be neat. -- Andrei
>
> Fun fact I found out using this thread: 57.4% of the lines in Phobos are
> non-code lines.

That's kinda where it could reasonably be, and also it's a good testament of the docs-in-code approach. Thanks for the insight! -- Andrei

On 02/26/2017 01:37 AM, Seb wrote:
> That been said DUB is a build tool and it's good to be in verbose in
> case of errors and there's `-q` which you can use as expected, e.g:
>
>> dub run dscanner -q -- --sloc .

Cool, that does it for me. Thanks! -- Andrei

On Saturday, 25 February 2017 at 19:55:04 UTC, Timothee Cour wrote:
> Try dscanner --sloc although IMO --tokenCount should be the most relevant
> metric (only caveat is mixin strings with which one could cheat to make
> token count smaller).
> TokenCount formatting invariant
>
> On Feb 25, 2017 11:36 AM, "Andrei Alexandrescu via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> What would be a simple way to count the "effective" lines in a module, i.e. excluding ddoc comments and unittests? Having a tool for that in tools/ would be neat. -- Andrei

The SLOC count is incorrect in Dscanner, for example for https://github.com/Hackerpilot/Dscanner/blob/master/src/highlighter.d it indicates 38...