The "src" subdirectory of go does balance, but building every ".go" file in
./go does lose the balance. I sensed your discomfort so I've changed my
plans a little to take as day to make a flexible command line tool out of
my go-test so that with it's verbose mode you'll know which files have
issues. I am here working on it at this very moment...
// Survey gathers and reports simple statistics about Go code by lexical
analysis
// Author: Michael Jones
//
// Survey files named in the file list of the "-f" argument and then those
listed in command line
// arguments. Files may be ".go" files or directories. If a named file is a
directory then all ".go"
// files in that directory are surveyed without considering subdirectories.
With the "-r" flag,
// named directories are processed recursively, eventually finding and
surveying each ".go" file in
// that hierarchy. The verbose argument requests details of individual file
processing and
// file system traversal, mentioning files with unbalanced "()[]{}." The
markdown argument prepares
// output for pretty display.
On Wed, Jun 12, 2019 at 10:27 PM Volker Dobler <dr.volker.dob...@gmail.com>
wrote:
>
> On Wednesday, 12 June 2019 23:48:36 UTC+2, Michael Jones wrote:
>>
>> Volker, did you see a few posts back that I did the run Roger asked
>> about, on RSC’s huge corpus? It is about 10x the size and its parens,
>> braces, and brackets match just fine, all *7476284* of them....
>>
>
> If I remember the corpus was curated to be buildable, but on
> the other hand the Go 1.13 codebase in master should be
> buildable always too, anytime. Weird.
>
> V.
>
>
>>
>> On Wed, Jun 12, 2019 at 2:13 PM Michael Jones <michae...@gmail.com>
>> wrote:
>>
>>> They matched up until yesterday. When I updated at 2am California time
>>> it changed. It also had no "0o" octal literals up until the latest.
>>>
>>> I'd planned to joke how the race was on to be the first to check in a
>>> new octal literal in my mail, but a few of those snuck in too.
>>>
>>> Yesterday:
>>> Count | Frequency | Detail
>>> ---:|---:|---
>>> 929548 | 19.7889% | ,
>>> 574886 | 12.2386% | .
>>>
>>> * 544819 | 11.5985% | ( 544819 | 11.5985% | ) *
>>>
>>> * 352547 | 7.5053% | { 352547 | 7.5053% | } *
>>> 288042 | 6.1321% | =
>>> 253563 | 5.3980% | :
>>> 155297 | 3.3061% | :=
>>>
>>> *138465 | 2.9478% | [ 138465 | 2.9478% | ] *
>>> 78567 | 1.6726% | !=
>>> 72007 | 1.5329% | *
>>>
>>> On Wed, Jun 12, 2019 at 1:51 PM Volker Dobler <dr.volk...@gmail.com>
>>> wrote:
>>>
>>>> Cool work!
>>>>
>>>> What I found most astonishing on a first look: Not all
>>>> parentheses ( are closed: 4 ) seem to be missing??
>>>> For { 5 are unclosed while there is one more ] than [ ?
>>>>
>>>> Are you parsing testfiles with deliberate errors?
>>>>
>>>> V.
>>>>
>>>> On Wednesday, 12 June 2019 15:08:44 UTC+2, Michael Jones wrote:
>>>>>
>>>>> I've been working on a cascade of projects, each needing the next as a
>>>>> part, the most recent being rewriting text.Scanner. It was not a goal, but
>>>>> the existing scanner does not do what I need (recognize Go operators,
>>>>> number types, and more) and my shim code was nearly as big as the standard
>>>>> library scanner itself, so I just sat down an rewrote it cleanly.
>>>>>
>>>>> To test beyond hand-crafted edge cases it seemed good to try it
>>>>> against a large body of Go code. I chose the Go 1.13 code base, and
>>>>> because
>>>>> the results are interesting on their own beyond my purpose of code
>>>>> testing,
>>>>> I thought to share what I've noticed as a Github Gist on the subject of
>>>>> the
>>>>> "Go Popularity Contest"—what are the most used types, most referenced
>>>>> packages, most and least popular operators, etc. The data are interesting,
>>>>> but I'll let it speak for itself. Find it here:
>>>>>
>>>>> https://gist.github.com/MichaelTJones/ca0fd339401ebbe79b9cbb5044afcfe2
>>>>>
>>>>> Michael
>>>>>
>>>>> P.S. Generated by go test. I just cut off the "passed" line and posted
>>>>> it. ;-)
>>>>>
>>>>> --
>>>>>
>>>>> *Michael T. jonesmichae...@gmail.com*
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "golang-nuts" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to golan...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/golang-nuts/1a0e2b4b-9276-4418-929c-51888cf2c93a%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/golang-nuts/1a0e2b4b-9276-4418-929c-51888cf2c93a%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>>
>> *Michael T. jonesmichae...@gmail.com*
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e401f2d7-44e3-400a-846a-6f3276f0698d%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/e401f2d7-44e3-400a-846a-6f3276f0698d%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
*Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>*
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CALoEmQwJaxWXmh4YK%2BofmwS5tBwd8p%3D9m7bfQkC%2BA9s4onygBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
