www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Code size without documentation comments and unittests

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 25 2017
next sibling parent reply Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Feb 25 2017
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 25 2017
next sibling parent reply Seb <seb wilzba.ch> writes:
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".

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
Feb 25 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 26 2017
parent reply hmm <hmm here.com> writes:
On Sunday, 26 February 2017 at 21:25:52 UTC, Andrei Alexandrescu 
wrote:

 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


Are you sure?


 The "--sloc" or "-l" option prints the number of lines of code 
 in the file. Instead of simply printing the number of line 
 breaks, this counts the number of semicolon, while, if, do, 
 else, switch, for, foreach, foreach_reverse, default, and case 
 tokens in the file.


https://github.com/Hackerpilot/Dscanner

Which means it includes code in unittests.
Feb 26 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/26/17 4:53 PM, hmm wrote:

 On Sunday, 26 February 2017 at 21:25:52 UTC, Andrei Alexandrescu wrote:

 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


 Are you sure?


 The "--sloc" or "-l" option prints the number of lines of code in the
 file. Instead of simply printing the number of line breaks, this
 counts the number of semicolon, while, if, do, else, switch, for,
 foreach, foreach_reverse, default, and case tokens in the file.


 https://github.com/Hackerpilot/Dscanner

 Which means it includes code in unittests.


Apparently I was wrong. Thanks for the correction! -- Andrei
Feb 26 2017
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/26/17 7:59 PM, Andrei Alexandrescu wrote:

 On 2/26/17 4:53 PM, hmm wrote:

 On Sunday, 26 February 2017 at 21:25:52 UTC, Andrei Alexandrescu wrote:

 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


 Are you sure?


 The "--sloc" or "-l" option prints the number of lines of code in the
 file. Instead of simply printing the number of line breaks, this
 counts the number of semicolon, while, if, do, else, switch, for,
 foreach, foreach_reverse, default, and case tokens in the file.


 https://github.com/Hackerpilot/Dscanner

 Which means it includes code in unittests.


 Apparently I was wrong. Thanks for the correction! -- Andrei


Ergh, I did the undignified: removed all doc comments and unittessts 
from std.experimental.checkedint. Got 1111 lines. -- Andrei
Feb 26 2017
prev sibling next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
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.
Feb 25 2017
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Feb 26 2017
prev sibling parent Guest <guessov nowhere.ch> writes:
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...
Feb 26 2017
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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.
Feb 25 2017
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 26 2017