Re: [NEW] textproc/loccount 1.2
Thanks, i imported it. Stuart Henderson(s...@spacehopper.org) on 2017.12.29 16:12:03 +: > On 2017/12/27 22:04, Sebastian Benoit wrote: > > Klemens Nanni(k...@posteo.org) on 2017.12.25 16:41:42 +0100: > > > On Thu, Nov 09, 2017 at 12:11:05AM +0100, Klemens Nanni wrote: > > > > Hey ports@, > > > > > > > > here's https://gitlab.com/esr/loccount/, from DESCR: > > > > > > > > loccount is a re-implementation of David A. Wheeler's sloccount tool in > > > > Go. It is faster and handles more different languages. Because it's one > > > > source file in Go, it is easier to maintain and extend than the > > > > multi-file, multi-language implementation of the original. > > > > > > > > The algorithms are largely unchanged and can be expected to produce > > > > identical numbers for languages supported by both tools. Python is an > > > > exception; loccount corrects buggy counting of single-quote multiline > > > > literals in sloccount 2.26. > > > 1.2 from 05.12.2017 fixes a bug in the parallelized treewalker so here's > > > an updated tarball including all of the previous feedback of course. > > > > > > Anyone willing to commit this? > > > > yeah, i can do this. > > any oks? sthen? > > OK to import. > > (I'd rather re-wrap DESCR, wrapping hard on 80 columns is a bit awkward > to read, and it doesn't take any more lines wrapping with fmt(1) or > par(1) default settings, but that doesn't block import). > --
Re: [NEW] textproc/loccount 1.2
On 2017/12/27 22:04, Sebastian Benoit wrote: > Klemens Nanni(k...@posteo.org) on 2017.12.25 16:41:42 +0100: > > On Thu, Nov 09, 2017 at 12:11:05AM +0100, Klemens Nanni wrote: > > > Hey ports@, > > > > > > here's https://gitlab.com/esr/loccount/, from DESCR: > > > > > > loccount is a re-implementation of David A. Wheeler's sloccount tool in > > > Go. It is faster and handles more different languages. Because it's one > > > source file in Go, it is easier to maintain and extend than the > > > multi-file, multi-language implementation of the original. > > > > > > The algorithms are largely unchanged and can be expected to produce > > > identical numbers for languages supported by both tools. Python is an > > > exception; loccount corrects buggy counting of single-quote multiline > > > literals in sloccount 2.26. > > 1.2 from 05.12.2017 fixes a bug in the parallelized treewalker so here's > > an updated tarball including all of the previous feedback of course. > > > > Anyone willing to commit this? > > yeah, i can do this. > any oks? sthen? OK to import. (I'd rather re-wrap DESCR, wrapping hard on 80 columns is a bit awkward to read, and it doesn't take any more lines wrapping with fmt(1) or par(1) default settings, but that doesn't block import).
Re: [NEW] textproc/loccount 1.2
Klemens Nanni(k...@posteo.org) on 2017.12.25 16:41:42 +0100: > On Thu, Nov 09, 2017 at 12:11:05AM +0100, Klemens Nanni wrote: > > Hey ports@, > > > > here's https://gitlab.com/esr/loccount/, from DESCR: > > > > loccount is a re-implementation of David A. Wheeler's sloccount tool in > > Go. It is faster and handles more different languages. Because it's one > > source file in Go, it is easier to maintain and extend than the > > multi-file, multi-language implementation of the original. > > > > The algorithms are largely unchanged and can be expected to produce > > identical numbers for languages supported by both tools. Python is an > > exception; loccount corrects buggy counting of single-quote multiline > > literals in sloccount 2.26. > 1.2 from 05.12.2017 fixes a bug in the parallelized treewalker so here's > an updated tarball including all of the previous feedback of course. > > Anyone willing to commit this? yeah, i can do this. any oks? sthen?
Re: [NEW] textproc/loccount 1.2
On Thu, Nov 09, 2017 at 12:11:05AM +0100, Klemens Nanni wrote: > Hey ports@, > > here's https://gitlab.com/esr/loccount/, from DESCR: > > loccount is a re-implementation of David A. Wheeler's sloccount tool in > Go. It is faster and handles more different languages. Because it's one > source file in Go, it is easier to maintain and extend than the > multi-file, multi-language implementation of the original. > > The algorithms are largely unchanged and can be expected to produce > identical numbers for languages supported by both tools. Python is an > exception; loccount corrects buggy counting of single-quote multiline > literals in sloccount 2.26. 1.2 from 05.12.2017 fixes a bug in the parallelized treewalker so here's an updated tarball including all of the previous feedback of course. Anyone willing to commit this? loccount.tgz Description: Binary data
Re: [NEW] textproc/loccount
On Sun, Dec 03, 2017 at 11:57:16AM +, Stuart Henderson wrote: > What I am saying is, the DESCR file is first and foremost there to > describe what the thing does. That is what should be first in the file. > Your rewritten DESCR still has "loccount is a re-implementation of David A. > Wheeler's sloccount tool in Go" at the top of the file. Take three first describing the port and then mentioning sloccount. I also flipped the order of mentioning of JSON and cost estimation to avoid misinterpretation: only SLOCs may be emitted in JSON while the costs stay as they are. loccount.tgz Description: application/tar-gz
Re: [NEW] textproc/loccount
On 2017/12/03 00:52, Klemens Nanni wrote: > On Sat, Dec 02, 2017 at 09:26:43PM +, Stuart Henderson wrote: > > On 2017/12/02 01:59, Klemens Nanni wrote: > > > Will "# statically linked" suffice? > > > > Yes. > > > > How about this diff on top of my tarball? > > > > Please send updated tarballs for changes to a new port - a diff in the > > accompanying mail can help to explain changes, but it's better not to > > ask reviewers to dig through old mails to assemble the whole thing. > New tarball attached incorporating all your feedback. > > > This still makes the whole file revolve around the fact that it's a > > reimplementation of sloccount. That's really of minor interest to DESCR, > > the primary function is to say what the package does - if the details of > > a similar program are needed at all then one paragraph at the bottom > > should suffice? > Point taken. > > > (Something like "loccount is a re-implementation of David A. Wheeler's > > sloccount tool in Go. The algorithms are largely unchanged and, bugs > > excepted, can be expected to produce identical numbers for languages > > supported by both tools." perhaps ..) > I slightly rephrased your suggestion and described how it works/what it > does. What I am saying is, the DESCR file is first and foremost there to describe what the thing does. That is what should be first in the file. Your rewritten DESCR still has "loccount is a re-implementation of David A. Wheeler's sloccount tool in Go" at the top of the file. Apart from DESCR this looks good to me.
Re: [NEW] textproc/loccount
On Sat, Dec 02, 2017 at 09:26:43PM +, Stuart Henderson wrote: > On 2017/12/02 01:59, Klemens Nanni wrote: > > Will "# statically linked" suffice? > > Yes. > > How about this diff on top of my tarball? > > Please send updated tarballs for changes to a new port - a diff in the > accompanying mail can help to explain changes, but it's better not to > ask reviewers to dig through old mails to assemble the whole thing. New tarball attached incorporating all your feedback. > This still makes the whole file revolve around the fact that it's a > reimplementation of sloccount. That's really of minor interest to DESCR, > the primary function is to say what the package does - if the details of > a similar program are needed at all then one paragraph at the bottom > should suffice? Point taken. > (Something like "loccount is a re-implementation of David A. Wheeler's > sloccount tool in Go. The algorithms are largely unchanged and, bugs > excepted, can be expected to produce identical numbers for languages > supported by both tools." perhaps ..) I slightly rephrased your suggestion and described how it works/what it does. loccount.tgz Description: application/tar-gz
Re: [NEW] textproc/loccount
On 2017/12/02 01:59, Klemens Nanni wrote:
> On Fri, Dec 01, 2017 at 02:26:06PM +, Stuart Henderson wrote:
> > : COMMENT = Faster Go re-implementation of sloccount for more
> > languages
> >
> > just describe what it does rather than say things like "faster
> > reimplementation" and "more". in particular it's quite useless to
> > have a package comparing itself with something else that isn't in
> > packages.
> Fair points, I've updated COMMENTS and simply included SLOCCount's
> description from https://www.dwheeler.com/sloccount/ (mostly matching
> what benno@ used) in DESCR.
>
> > : WANTLIB = c pthread
> >
> > loccount-1.1(textproc/loccount):
> > Extra: c.92 pthread.25
> >
> > if you're adding WANTLIB in the hope that it triggers an update in a
> > statically
> > linked program, add a comment explaining why, otherwise it is likely to be
> > removed
> > in a WANTLIB sync.
> Will "# statically linked" suffice?
Yes.
> > : MODULES = lang/go
> >
> > there doesn't seem much advantage to using the lang/go module when
> > you're not using the go build scaffolding.
> >
> > : ALL_TARGET =${HOMEPAGE:https://%=%}
> >
> > this is a bit obtuse, if you were actually using it, it would be simpler
> > to just use the string.
> >
> > but you're not actually using it.
> Yeah, I started with MODULES=lang/go basically and made it "work"...
>
> > : WRKSRC =${MODGO_WORKSPACE}/src/${ALL_TARGET}
> > :
> > : do-build:
> > : make -C ${WRKSRC} loccount{,.1}
> > :
> > : do-test:
> > : make -C ${WRKSRC} check
> >
> > normally ${MAKE_PROGRAM} rather than calling make directly, but seems
> > simpler to get rid of the MODULES and have something like this instead
> >
> > BUILD_DEPENDS = textproc/asciidoc \
> > lang/go
> >
> > ALL_TARGET =loccount loccount.1
> >
> > do-install:
> > ${INSTALL_PROGRAM} ${WRKSRC}/loccount-$V-* ${PREFIX}/bin/loccount
> > ${INSTALL_MAN} ${WRKSRC}/loccount.1 ${PREFIX}/man/man1/
> >
> ... or not. This port is made around it's Makefile not the Go build
> environment as seen in my MODULES approach; I went through this multiple
> times now and ditching it in favor of BUILD_DEPENDS is indeed clearer.
>
> How about this diff on top of my tarball?
Please send updated tarballs for changes to a new port - a diff in the
accompanying mail can help to explain changes, but it's better not to
ask reviewers to dig through old mails to assemble the whole thing.
> The symlink in post-build makes the test work and avoids -${V}-* in
> install.
>
> Thanks a lot for your feedback!
>
> ---
> textproc/loccount/Makefile | 19 ---
> textproc/loccount/pkg/DESCR | 19 +++
> 2 files changed, 27 insertions(+), 11 deletions(-)
>
> diff --git a/textproc/loccount/Makefile b/textproc/loccount/Makefile
> index 8a8319e83eb..a263287844a 100644
> --- a/textproc/loccount/Makefile
> +++ b/textproc/loccount/Makefile
> @@ -1,6 +1,6 @@
> # $OpenBSD: $
>
> -COMMENT =Faster Go re-implementation of sloccount for more
> languages
> +COMMENT =Count lines of codes in many languages
lowercase Count
> V = 1.1
> DISTNAME = loccount-${V}
> @@ -16,20 +16,17 @@ MASTER_SITES =${HOMEPAGE}/repository/
> # BSD
> PERMIT_PACKAGE_CDROM = Yes
>
> +# statically linked
> WANTLIB =c pthread
>
> -MODULES =lang/go
> +BUILD_DEPENDS = lang/go \
> + textproc/asciidoc
>
> -BUILD_DEPENDS = textproc/asciidoc
> +ALL_TARGET = loccount{,.1}
not a fan of relying on shell expansions for a make variable unless
there's no other way, it's clearer like this:
ALL_TARGET =loccount loccount.1
> +TEST_TARGET =check
>
> -ALL_TARGET = ${HOMEPAGE:https://%=%}
> -WRKSRC = ${MODGO_WORKSPACE}/src/${ALL_TARGET}
> -
> -do-build:
> - make -C ${WRKSRC} loccount{,.1}
> -
> -do-test:
> - make -C ${WRKSRC} check
> +post-build:
> + ln -sf ${WRKBUILD}/loccount{-${V}-*,}
>
> do-install:
> ${INSTALL_PROGRAM} ${WRKSRC}/loccount ${PREFIX}/bin/
> diff --git a/textproc/loccount/pkg/DESCR b/textproc/loccount/pkg/DESCR
> index 798b459ddb7..8f58a059091 100644
> --- a/textproc/loccount/pkg/DESCR
> +++ b/textproc/loccount/pkg/DESCR
> @@ -6,3 +6,22 @@ implementation of the original.
> The algorithms are largely unchanged and can be expected to produce identical
> numbers for languages supported by both tools. Python is an exception;
> loccount
> corrects buggy counting of single-quote multiline literals in sloccount 2.26.
> +
> +
> +SLOCCount includes a number of heuristics, so it can automatically detect
> file
> +types, even those that don't use the "standard" extensions, and conversely,
> it
> +can detect many files that have a standard extension but aren't really of
> that
Re: [NEW] textproc/loccount
On Fri, Dec 01, 2017 at 02:26:06PM +, Stuart Henderson wrote:
> : COMMENT = Faster Go re-implementation of sloccount for more
> languages
>
> just describe what it does rather than say things like "faster
> reimplementation" and "more". in particular it's quite useless to
> have a package comparing itself with something else that isn't in
> packages.
Fair points, I've updated COMMENTS and simply included SLOCCount's
description from https://www.dwheeler.com/sloccount/ (mostly matching
what benno@ used) in DESCR.
> : WANTLIB = c pthread
>
> loccount-1.1(textproc/loccount):
> Extra: c.92 pthread.25
>
> if you're adding WANTLIB in the hope that it triggers an update in a
> statically
> linked program, add a comment explaining why, otherwise it is likely to be
> removed
> in a WANTLIB sync.
Will "# statically linked" suffice?
> : MODULES = lang/go
>
> there doesn't seem much advantage to using the lang/go module when
> you're not using the go build scaffolding.
>
> : ALL_TARGET =${HOMEPAGE:https://%=%}
>
> this is a bit obtuse, if you were actually using it, it would be simpler
> to just use the string.
>
> but you're not actually using it.
Yeah, I started with MODULES=lang/go basically and made it "work"...
> : WRKSRC =${MODGO_WORKSPACE}/src/${ALL_TARGET}
> :
> : do-build:
> : make -C ${WRKSRC} loccount{,.1}
> :
> : do-test:
> : make -C ${WRKSRC} check
>
> normally ${MAKE_PROGRAM} rather than calling make directly, but seems
> simpler to get rid of the MODULES and have something like this instead
>
> BUILD_DEPENDS = textproc/asciidoc \
> lang/go
>
> ALL_TARGET = loccount loccount.1
>
> do-install:
> ${INSTALL_PROGRAM} ${WRKSRC}/loccount-$V-* ${PREFIX}/bin/loccount
> ${INSTALL_MAN} ${WRKSRC}/loccount.1 ${PREFIX}/man/man1/
>
... or not. This port is made around it's Makefile not the Go build
environment as seen in my MODULES approach; I went through this multiple
times now and ditching it in favor of BUILD_DEPENDS is indeed clearer.
How about this diff on top of my tarball?
The symlink in post-build makes the test work and avoids -${V}-* in
install.
Thanks a lot for your feedback!
---
textproc/loccount/Makefile | 19 ---
textproc/loccount/pkg/DESCR | 19 +++
2 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/textproc/loccount/Makefile b/textproc/loccount/Makefile
index 8a8319e83eb..a263287844a 100644
--- a/textproc/loccount/Makefile
+++ b/textproc/loccount/Makefile
@@ -1,6 +1,6 @@
# $OpenBSD: $
-COMMENT = Faster Go re-implementation of sloccount for more
languages
+COMMENT = Count lines of codes in many languages
V =1.1
DISTNAME = loccount-${V}
@@ -16,20 +16,17 @@ MASTER_SITES = ${HOMEPAGE}/repository/
# BSD
PERMIT_PACKAGE_CDROM = Yes
+# statically linked
WANTLIB = c pthread
-MODULES = lang/go
+BUILD_DEPENDS =lang/go \
+ textproc/asciidoc
-BUILD_DEPENDS =textproc/asciidoc
+ALL_TARGET = loccount{,.1}
+TEST_TARGET = check
-ALL_TARGET = ${HOMEPAGE:https://%=%}
-WRKSRC = ${MODGO_WORKSPACE}/src/${ALL_TARGET}
-
-do-build:
- make -C ${WRKSRC} loccount{,.1}
-
-do-test:
- make -C ${WRKSRC} check
+post-build:
+ ln -sf ${WRKBUILD}/loccount{-${V}-*,}
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/loccount ${PREFIX}/bin/
diff --git a/textproc/loccount/pkg/DESCR b/textproc/loccount/pkg/DESCR
index 798b459ddb7..8f58a059091 100644
--- a/textproc/loccount/pkg/DESCR
+++ b/textproc/loccount/pkg/DESCR
@@ -6,3 +6,22 @@ implementation of the original.
The algorithms are largely unchanged and can be expected to produce identical
numbers for languages supported by both tools. Python is an exception;
loccount
corrects buggy counting of single-quote multiline literals in sloccount 2.26.
+
+
+SLOCCount includes a number of heuristics, so it can automatically detect file
+types, even those that don't use the "standard" extensions, and conversely, it
+can detect many files that have a standard extension but aren't really of that
+type. The SLOC counters have enough smarts to handle oddities of several
+languages. For example, SLOCCount examines assembly language files, determines
+the comment scheme, and then correctly counts the lines automatically. It also
+correctly handles language constructs that are often mishandled by other tools,
+such as Python's constant strings when used as comments and Perl's "perlpod"
+documentation.
+
+SLOCCount will even automatically estimate the effort, time, and money it would
+take to develop the software (if it was developed as traditional proprietary
+software). Without options, it will use the basic COCOMO model, which makes
+these estimates solely
Re: [NEW] textproc/loccount
On 2017/12/01 14:54, Klemens Nanni wrote:
> On Thu, Nov 09, 2017 at 12:11:05AM +0100, Klemens Nanni wrote:
> > Hey ports@,
> >
> > here's https://gitlab.com/esr/loccount/, from DESCR:
> >
> > loccount is a re-implementation of David A. Wheeler's sloccount tool in
> > Go. It is faster and handles more different languages. Because it's one
> > source file in Go, it is easier to maintain and extend than the
> > multi-file, multi-language implementation of the original.
> >
> > The algorithms are largely unchanged and can be expected to produce
> > identical numbers for languages supported by both tools. Python is an
> > exception; loccount corrects buggy counting of single-quote multiline
> > literals in sloccount 2.26.
> >
> > Tested on amd64, here's an example:
> >
> > $ time loccount /usr/src/sys
> > all 2010138 (100.00%) in 5939 files
> > c1943636 (96.69%) in 2762 files
> > asm58178 (2.89%) in 254 files
> > makefile3023 (0.15%) in 207 files
> > awk 2096 (0.10%) in 18 files
> > yacc1654 (0.08%) in 2 files
> > shell738 (0.04%) in 8 files
> > lex 560 (0.03%) in 2 files
> > m4 175 (0.01%) in 1 files
> > perl 70 (0.00%) in 2 files
> > ada8 (0.00%) in 1 files
> > 0m02.69s real 0m06.07s user 0m01.15s system
> >
> > Feedback, comments?
> Anyone willing to commit this? It still works fine after the lang/go
> 1.9.2 update, I'm using it regularily.
>
: # $OpenBSD: $
:
: COMMENT = Faster Go re-implementation of sloccount for more
languages
just describe what it does rather than say things like "faster
reimplementation" and "more". in particular it's quite useless to
have a package comparing itself with something else that isn't in
packages.
something like "count lines of code in various languages"?
: V = 1.1
: DISTNAME = loccount-${V}
: CATEGORIES =textproc
:
: HOMEPAGE = https://gitlab.com/esr/loccount
:
: DISTFILES = ${DISTNAME}{${V}/archive}${EXTRACT_SUFX}
: WRKDIST =
${WRKDIR}/${DISTNAME}-a4b1199c68660884eb183aecd128102c0c1fbfb8
:
: MASTER_SITES = ${HOMEPAGE}/repository/
:
: # BSD
: PERMIT_PACKAGE_CDROM = Yes
:
: WANTLIB = c pthread
loccount-1.1(textproc/loccount):
Extra: c.92 pthread.25
if you're adding WANTLIB in the hope that it triggers an update in a statically
linked program, add a comment explaining why, otherwise it is likely to be
removed
in a WANTLIB sync.
: BUILD_DEPENDS = textproc/asciidoc
:
: MODULES = lang/go
there doesn't seem much advantage to using the lang/go module when
you're not using the go build scaffolding.
: ALL_TARGET =${HOMEPAGE:https://%=%}
this is a bit obtuse, if you were actually using it, it would be simpler
to just use the string.
but you're not actually using it.
: WRKSRC =${MODGO_WORKSPACE}/src/${ALL_TARGET}
:
: do-build:
: make -C ${WRKSRC} loccount{,.1}
:
: do-test:
: make -C ${WRKSRC} check
normally ${MAKE_PROGRAM} rather than calling make directly, but seems
simpler to get rid of the MODULES and have something like this instead
BUILD_DEPENDS = textproc/asciidoc \
lang/go
ALL_TARGET =loccount loccount.1
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/loccount-$V-* ${PREFIX}/bin/loccount
${INSTALL_MAN} ${WRKSRC}/loccount.1 ${PREFIX}/man/man1/
... there's a remaining problem of this package not being updated
when the go compiler itself is updated (which likely results in changes
in the built code), though this affects all go ports other than
"MODGO_TYPE=lib" ones.
:
: do-install:
: ${INSTALL_PROGRAM} ${WRKSRC}/loccount ${PREFIX}/bin/
: ${INSTALL_MAN} ${WRKSRC}/loccount.1 ${PREFIX}/man/man1/
:
:
Re: [NEW] textproc/loccount
On Thu, Nov 09, 2017 at 12:11:05AM +0100, Klemens Nanni wrote: > Hey ports@, > > here's https://gitlab.com/esr/loccount/, from DESCR: > > loccount is a re-implementation of David A. Wheeler's sloccount tool in > Go. It is faster and handles more different languages. Because it's one > source file in Go, it is easier to maintain and extend than the > multi-file, multi-language implementation of the original. > > The algorithms are largely unchanged and can be expected to produce > identical numbers for languages supported by both tools. Python is an > exception; loccount corrects buggy counting of single-quote multiline > literals in sloccount 2.26. > > Tested on amd64, here's an example: > > $ time loccount /usr/src/sys > all 2010138 (100.00%) in 5939 files > c1943636 (96.69%) in 2762 files > asm58178 (2.89%) in 254 files > makefile3023 (0.15%) in 207 files > awk 2096 (0.10%) in 18 files > yacc1654 (0.08%) in 2 files > shell738 (0.04%) in 8 files > lex 560 (0.03%) in 2 files > m4 175 (0.01%) in 1 files > perl 70 (0.00%) in 2 files > ada8 (0.00%) in 1 files > 0m02.69s real 0m06.07s user 0m01.15s system > > Feedback, comments? Anyone willing to commit this? It still works fine after the lang/go 1.9.2 update, I'm using it regularily.
[NEW] textproc/loccount
Hey ports@, here's https://gitlab.com/esr/loccount/, from DESCR: loccount is a re-implementation of David A. Wheeler's sloccount tool in Go. It is faster and handles more different languages. Because it's one source file in Go, it is easier to maintain and extend than the multi-file, multi-language implementation of the original. The algorithms are largely unchanged and can be expected to produce identical numbers for languages supported by both tools. Python is an exception; loccount corrects buggy counting of single-quote multiline literals in sloccount 2.26. Tested on amd64, here's an example: $ time loccount /usr/src/sys all 2010138 (100.00%) in 5939 files c1943636 (96.69%) in 2762 files asm58178 (2.89%) in 254 files makefile3023 (0.15%) in 207 files awk 2096 (0.10%) in 18 files yacc1654 (0.08%) in 2 files shell738 (0.04%) in 8 files lex 560 (0.03%) in 2 files m4 175 (0.01%) in 1 files perl 70 (0.00%) in 2 files ada8 (0.00%) in 1 files 0m02.69s real 0m06.07s user 0m01.15s system Feedback, comments? loccount.tgz Description: application/tar-gz
