Re: [go-nuts] Re: Go Language Survey

[Volker Dobler]

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  > 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 > > 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
>>>  
>>> 
>>> .
>>> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] cannot find package "text/template"

[ThisEndUp]

All of a sudden, when trying to build programs that used to work, as 
recently as a couple of days ago, I'm getting

main.go:6:2: cannot find package "text/template" in any of:
 C:\Go\src\text\template (from $GOROOT)
 D:\\Go\src\text\template (from $GOPATH)


I was trying this in a module, but when the error popped up, I copied the 
program into a directory in $GOPATH/src and got the same result.

go version reports "go1.12 windows/amd64". I'm using a 64-bit Windows 10 
Home machine.

Is anyone else experiencing this? Is it temporary? Is there a work-around?

Thanks!

-- 
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/6a1bc61e-4367-4b43-b24c-056ee7a79ec8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go will shine on huge web projects, but how about simple ones?

[Tong Sun]

Yeah, no doubt, I totally agree with that as well.

But now, I can proudly say ...

My Go beats C :-)

On Thu, Jun 13, 2019 at 12:09 AM Justin Israel  wrote:
>
>
>
> On Thu, Jun 13, 2019 at 4:05 PM Tong Sun  wrote:
>>
>> Yep, thanks Justin, both your points really made the difference,
>> because I do believe that the buffered socket write is the key
>> component for the 3-time improvement that I'm getting (from using
>> FastHTTP), IMHO. And FastHTTP recommends GOMAXPROCS=1 too, which I
>> used this time as well.
>>
>> So thanks again, Justin & Ronny!
>
>
> Cool. Glad that actually helped. I do feel with your results, and in 
> agreement with others,  that you really are comparing Go to the underlying C 
> implementation of php, with everything stripped back so far. But at least you 
> are happy with your results!
>
>>
>> On Sat, Jun 8, 2019 at 10:54 PM Justin Israel  wrote:
>> >
>> > I'm wondering about a couple factors in this comparison that seem to make 
>> > a difference in my local test:
>> >
>> > I think perl sockets are write buffered. So would the equivalent be to 
>> > wrap the net.Conn in bufio.NewWriter(c) and flush before the Close?
>> > Since this is a straigh-line test where both servers are not using 
>> > concurrent handling of connections (uncommon for a Go server even on 1 
>> > core), would it not make sense to run the Go server with GOMAXPROCS=1?
>> >
>> > - Justin
>> >
>> > On Saturday, June 8, 2019 at 1:36:49 AM UTC+12, Tong Sun wrote:
>> >>
>> >> I had always believed that the web projects build with Go should be much 
>> >> faster than Perl, since Go is a compiled language.
>> >>
>> >> However that belief was crushed brutally last night, when I did a 
>> >> comparison -- the Go implementation is 8 times worse than the Perl! -- 
>> >> the mean response time jumped from 6ms to 48ms.
>> >>
>> >> I know this is the simplest possible web server, but still, when it comes 
>> >> to simple web servers like this, I have to say that Perl performs much 
>> >> better than Go.
>> >>
>> >> I don't think there is much I can twist on the Go side, since it can't be 
>> >> more simpler than that. However, I also believe it won't hurt to ask and 
>> >> confirm. So,
>> >>
>> >> Have I missed anything? Is it possible for me to make my Go 
>> >> implementation anywhere near the Perl's performance?
>> >>
>> >> Thanks
>> >>
>> >>
>> > --
>> > You received this message because you are subscribed to a topic in the 
>> > Google Groups "golang-nuts" group.
>> > To unsubscribe from this topic, visit 
>> > https://groups.google.com/d/topic/golang-nuts/iH2Ck_hpCpI/unsubscribe.
>> > To unsubscribe from this group and all its topics, 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/37a1ac7e-85ee-4775-b348-5673c41a162c%40googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.

-- 
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/CAMmz1OfyK5n7JyMy8MmL3ikB1mAdHtp1d1EZ_s269nHfZxxKEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go will shine on huge web projects, but how about simple ones?

[Justin Israel]

On Thu, Jun 13, 2019 at 4:05 PM Tong Sun  wrote:

> Yep, thanks Justin, both your points really made the difference,
> because I do believe that the buffered socket write is the key
> component for the 3-time improvement that I'm getting (from using
> FastHTTP), IMHO. And FastHTTP recommends GOMAXPROCS=1 too, which I
> used this time as well.
>
> So thanks again, Justin & Ronny!
>

Cool. Glad that actually helped. I do feel with your results, and in
agreement with others,  that you really are comparing Go to the underlying
C implementation of php, with everything stripped back so far. But at least
you are happy with your results!


> On Sat, Jun 8, 2019 at 10:54 PM Justin Israel 
> wrote:
> >
> > I'm wondering about a couple factors in this comparison that seem to
> make a difference in my local test:
> >
> > I think perl sockets are write buffered. So would the equivalent be to
> wrap the net.Conn in bufio.NewWriter(c) and flush before the Close?
> > Since this is a straigh-line test where both servers are not using
> concurrent handling of connections (uncommon for a Go server even on 1
> core), would it not make sense to run the Go server with GOMAXPROCS=1?
> >
> > - Justin
> >
> > On Saturday, June 8, 2019 at 1:36:49 AM UTC+12, Tong Sun wrote:
> >>
> >> I had always believed that the web projects build with Go should be
> much faster than Perl, since Go is a compiled language.
> >>
> >> However that belief was crushed brutally last night, when I did a
> comparison -- the Go implementation is 8 times worse than the Perl! -- the
> mean response time jumped from 6ms to 48ms.
> >>
> >> I know this is the simplest possible web server, but still, when it
> comes to simple web servers like this, I have to say that Perl performs
> much better than Go.
> >>
> >> I don't think there is much I can twist on the Go side, since it can't
> be more simpler than that. However, I also believe it won't hurt to ask and
> confirm. So,
> >>
> >> Have I missed anything? Is it possible for me to make my Go
> implementation anywhere near the Perl's performance?
> >>
> >> Thanks
> >>
> >>
> > --
> > You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> > To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/iH2Ck_hpCpI/unsubscribe.
> > To unsubscribe from this group and all its topics, 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/37a1ac7e-85ee-4775-b348-5673c41a162c%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAPGFgA2_oz-Frmw13oraLoeyzidwy_r4yWUfPNuqFFKefgG6DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go will shine on huge web projects, but how about simple ones?

[Tong Sun]

Yep, thanks Justin, both your points really made the difference,
because I do believe that the buffered socket write is the key
component for the 3-time improvement that I'm getting (from using
FastHTTP), IMHO. And FastHTTP recommends GOMAXPROCS=1 too, which I
used this time as well.

So thanks again, Justin & Ronny!

On Sat, Jun 8, 2019 at 10:54 PM Justin Israel  wrote:
>
> I'm wondering about a couple factors in this comparison that seem to make a 
> difference in my local test:
>
> I think perl sockets are write buffered. So would the equivalent be to wrap 
> the net.Conn in bufio.NewWriter(c) and flush before the Close?
> Since this is a straigh-line test where both servers are not using concurrent 
> handling of connections (uncommon for a Go server even on 1 core), would it 
> not make sense to run the Go server with GOMAXPROCS=1?
>
> - Justin
>
> On Saturday, June 8, 2019 at 1:36:49 AM UTC+12, Tong Sun wrote:
>>
>> I had always believed that the web projects build with Go should be much 
>> faster than Perl, since Go is a compiled language.
>>
>> However that belief was crushed brutally last night, when I did a comparison 
>> -- the Go implementation is 8 times worse than the Perl! -- the mean 
>> response time jumped from 6ms to 48ms.
>>
>> I know this is the simplest possible web server, but still, when it comes to 
>> simple web servers like this, I have to say that Perl performs much better 
>> than Go.
>>
>> I don't think there is much I can twist on the Go side, since it can't be 
>> more simpler than that. However, I also believe it won't hurt to ask and 
>> confirm. So,
>>
>> Have I missed anything? Is it possible for me to make my Go implementation 
>> anywhere near the Perl's performance?
>>
>> Thanks
>>
>>
> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/golang-nuts/iH2Ck_hpCpI/unsubscribe.
> To unsubscribe from this group and all its topics, 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/37a1ac7e-85ee-4775-b348-5673c41a162c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CAMmz1OdcaBxZV2fOBu6hR1EdoE2JF8Vprgj1s9rOapAhwv8BEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go will shine on huge web projects, but how about simple ones?

[Tong Sun]

On Mon, Jun 10, 2019 at 5:27 PM Tong Sun wrote:

> > IMO this is just not a meaningful test. Or its results are totally 
> > unsurprising.
>
> Again, I was trying to improve Perl performs with Go. That
> "ridiculously simple" Perl code is the foundation of the Debian dbab
> package, and I was trying to improve it.
>
> It might be meaningless to you but it is perfectly meaningful to me.

For those who care ... long story short, I finally made it, with helps
I got from various sources -- I finally made Go faster than Perl!
https://dev.to/suntong/simple-web-server-in-perl-and-go-finally-1kgh

-- 
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/CAMmz1Od51Cgqw6NE7DwodHT0NNfVvJwt60g6ri3EVKN3crX9qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[Dan Kortschak]

This is interesting. I have exactly the opposite situation; up-down is
much easier than significant left-right because of faulty saccades.

On Wed, 2019-06-12 at 11:41 -0700, Michael Jones wrote:
> Bakul, more good arguments. I have another motivation in the "?"
> world that
> I've not argued because it is personal/not general, but a decade ago
> I had
> two detached retinas, surgeries, and imperfect recovery. Part of my
> vision
> that I lost is just below the center...maybe -15 degrees to -40
> degrees.
> The brain knows when I want to see things things there and moves the
> eyes
> around to gather that part of the visual field. This "hunting" is
> tiring of
> the muscles and causes issues. left-to-right density is easy for me,
> vertical is very bad. Your:
> 
> x := b? 2 : 1
> 
> is instantaneous, a sight read; while the:
> 
> var x int
> if b {
>   x = 2
> } else {
>   x = 1
> }
> 
> and
> 
> x := 1
> if b {
>   x = 2
> }
> 
> ...feel like climbing Everest. It is hard to explain the difficulty.
> Fortunately it is not a widespread problem. Certainly not Go's
> problem, but
> I'd pay double for a "wide" mode where gofmt tolerated "var x int; if
> b { x
> = 2 } else { x = 1 }". In fact, now that i've just seen this, I am
> going to
> make a local version and hook it to vs code. Why did I not think of
> this
> before! Wow.

-- 
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/e256bf8c6f380acf4999385f4d1e557f1f201d6b.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Dan Kortschak]

I feel your pain. For me it's at the other end of the keyboard.

Dan

On Wed, 2019-06-12 at 17:01 -0700, Ian Lance Taylor wrote:
> On Wed, Jun 12, 2019 at 2:55 PM Dan Kortschak 
> wrote:
> > 
> > For others, the cl is https://golang.org/cl/181840 (note the extra
> > 0).
> 
> Thanks.
> 
> (My laptop keyboard is barely a year old and already becoming
> unreliable.)
> 
> Ian
> 
> 
> > On Wed, 2019-06-12 at 07:01 -0700, Ian Lance Taylor wrote:
> > > On Tue, Jun 11, 2019 at 6:30 PM Dan Kortschak 
> > > wrote:
> > > > 
> > > > Having that and exactly what it means in the go help modules
> > > > output
> > > > would probably be the best outcome.
> > > > 
> > > > Currently it's not mentioned in that output for the current
> > > > release
> > > > (1.12.6) and the meaning/implication of "expected [Go] language
> > > > version" is not defined in tip's version (f2a4c13).
> > > 
> > > I sent https://golang.org/cl/18184 to add some text to "go help
> > > go.mod".
> > > 
> > > Ian
> > > 
> > > > On Tue, 2019-06-11 at 17:35 -0700, Ian Lance Taylor wrote:
> > > > > On Tue, Jun 11, 2019 at 4:53 PM Dan Kortschak <
> > > > > d...@kortschak.io>
> > > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > It would be very nice if the documentation and clarity of
> > > > > > communication
> > > > > > around this were improved.
> > > > > 
> > > > > I struggle with what to say beyond "it sets the language
> > > > > version."
> > > > > Language features available as of that version will be
> > > > > available
> > > > > for
> > > > > use.  Language features removed in earlier versions, or added
> > > > > in
> > > > > later
> > > > > versions, will not be available.  For almost all users the
> > > > > default
> > > > > value will be correct.  At least, I hope that is the case.
> > > > > 
> > > > > Ian
> > > > > 
> > > 
> > > 

-- 
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/3a3a1981ebe3eb1ecd816f027e284cd5ce2df6a2.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] cgo behaviour change between go1.11.10 and go1.12.5

[Ian Lance Taylor]

On Wed, Jun 12, 2019 at 12:14 PM Neil Schellenberger
 wrote:
>
> Sorry for the delay in responding.  Filed as 
> https://github.com/golang/go/issues/32579.

Thanks.

Ian

> On Tue, Jun 11, 2019 at 1:21 AM Ian Lance Taylor  wrote:
>>
>> On Mon, Jun 10, 2019 at 9:14 PM Neil Schellenberger
>>  wrote:
>> >
>> > When upgrading our build container from 1.11.10 to 1.12.5, some of our 
>> > tests failed in a surprising way.  I've boiled down the issue to this 
>> > short example code fragment.
>> >
>> > package main
>> >
>> > // #include 
>> > // struct S { unsigned char data[18]; };
>> > import "C"
>> > import "unsafe"
>> >
>> > func main() {
>> > var array [5]C.struct_S
>> > for i := range array {
>> > C.memset(unsafe.Pointer([i].data[0]), 0xff, C.sizeof_struct_S)
>> > }
>> > for i := range array {
>> > for j := range array[i].data {
>> > if array[i].data[j] != C.uchar(0xff) {
>> > panic("oops")
>> > }
>> > }
>> > }
>> > }
>> >
>> > Under 1.11 this runs to completion; under 1.12 it panics.
>> >
>> > Debugging and instrumenting shows that the problem is the first argument 
>> > to memset is not what one would expect when run under 1.12.  (The address 
>> > of a heap temporary copy rather than the original perhaps?)
>> >
>> > Strangely, either parenthesising the argument expression to the address 
>> > operand ("&(array[i].data[0])") or removing the final index expression 
>> > ("[i].data") "fixes" the problem.
>> >
>> > I've spelunked through the AST (identical under both); the liveness and 
>> > escape analysis (different); the parse tree (different); and the go asm 
>> > (different).  Frankly, my gc-fu is very weak and I don't really know what 
>> > I'm looking for.
>> >
>> > I assume that the root cause is that we were violating some sort of 
>> > liveness or escape policy, but I can't figure out what it would be (or why 
>> > minor syntactic changes "fix" things).  I'd be quite curious to know.
>> >
>> > The workaround in the real code is simple, so this isn't a huge issue, 
>> > just a a bit of a mystery.
>>
>> It's a bug.  Would you mind opening an issue with this test case at
>> https://golang.org/issue?  Thanks.
>>
>> Ian

-- 
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/CAOyqgcWCKn3rOJKUQ%2B9U6km_ZEsT4BzhqwORNtDqBdDY7PQj-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Ian Lance Taylor]

On Wed, Jun 12, 2019 at 2:55 PM Dan Kortschak  wrote:
>
> For others, the cl is https://golang.org/cl/181840 (note the extra 0).

Thanks.

(My laptop keyboard is barely a year old and already becoming unreliable.)

Ian


> On Wed, 2019-06-12 at 07:01 -0700, Ian Lance Taylor wrote:
> > On Tue, Jun 11, 2019 at 6:30 PM Dan Kortschak 
> > wrote:
> > >
> > > Having that and exactly what it means in the go help modules output
> > > would probably be the best outcome.
> > >
> > > Currently it's not mentioned in that output for the current release
> > > (1.12.6) and the meaning/implication of "expected [Go] language
> > > version" is not defined in tip's version (f2a4c13).
> >
> > I sent https://golang.org/cl/18184 to add some text to "go help
> > go.mod".
> >
> > Ian
> >
> > > On Tue, 2019-06-11 at 17:35 -0700, Ian Lance Taylor wrote:
> > > > On Tue, Jun 11, 2019 at 4:53 PM Dan Kortschak 
> > > > wrote:
> > > > >
> > > > >
> > > > > It would be very nice if the documentation and clarity of
> > > > > communication
> > > > > around this were improved.
> > > >
> > > > I struggle with what to say beyond "it sets the language
> > > > version."
> > > > Language features available as of that version will be available
> > > > for
> > > > use.  Language features removed in earlier versions, or added in
> > > > later
> > > > versions, will not be available.  For almost all users the
> > > > default
> > > > value will be correct.  At least, I hope that is the case.
> > > >
> > > > Ian
> > > >
> >
> >
>

-- 
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/CAOyqgcWjyY9Y6405Ce13dON%3D60rc8o%3DwLH4KhZVtTvEbU9Ferg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Ian Lance Taylor]

On Wed, Jun 12, 2019 at 7:39 AM t hepudds  wrote:
>
> Thank you for sending that CL 181840.
>
> One minor request for clarification on the discussion here.
>
> When you said earlier in this thread:
>
> > “For almost all users the default
> value will be correct.  At least, I hope that is the case.”
>
> I *think* what you are saying is for almost everyone the default value set 
> should be a valid choice when initially selected by the 'go’ command, even 
> though someone might later need to manually change it in the future as new 
> language features are released?
>
> In other words, if hypothetically something like a new 'try' keyword lands in 
> something like Go 1.15, then at that point someone might need to change the 
> value in their go.mod from for example 'go 1.12'  to instead read 'go 1.15' 
> if they want to use the new language feature?
>
> Sorry if that is not correct.

Yes, that is how it works today.  We will have to see how that plays
out in practice.

Ian

-- 
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/CAOyqgcXEEFSyR3Dp_nPi8Tg1KxKM2WcJPLouQeZeUqSKcN0Xtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] https://godoc.org/github.com/couchbase/moss

[Gert]

thx, filed at https://github.com/golang/go/issues/32588

On Wednesday, June 12, 2019 at 11:48:20 PM UTC+2, andrey mirtchovski wrote:
>
> collection is not an exported type: 
> https://github.com/couchbase/moss/blob/master/collection.go#L24 
>
> the ?m=all parameter should enable you to see those, but it's not 
> working for me on your link. perhaps because "collection" and 
> "Collection" are not considered by godoc to be two different things? 
> you may have to file a bug. 
>
> here's more info on m=all: https://godoc.org/golang.org/x/tools/cmd/godoc 
>
> On Wed, Jun 12, 2019 at 3:25 PM Gert > 
> wrote: 
> > 
> > Is it just me or is stuff missing in godoc like for example 
> > 
> > // NewBatch returns a new Batch instance with hinted amount of 
> > // resources expected to be required. 
> > func (m *collection) NewBatch(totalOps, totalKeyValBytes int) ( 
> > ... 
> > } 
> > 
> > from collection.go 
> > 
> > https://godoc.org/github.com/couchbase/moss 
> > 
> > -- 
> > 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/fd93525d-f221-4d95-9f20-44dc60308538%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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/0a178836-4d40-4d3b-ba6d-44d1da2ea9a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Dan Kortschak]

For others, the cl is https://golang.org/cl/181840 (note the extra 0).

On Wed, 2019-06-12 at 07:01 -0700, Ian Lance Taylor wrote:
> On Tue, Jun 11, 2019 at 6:30 PM Dan Kortschak 
> wrote:
> > 
> > Having that and exactly what it means in the go help modules output
> > would probably be the best outcome.
> > 
> > Currently it's not mentioned in that output for the current release
> > (1.12.6) and the meaning/implication of "expected [Go] language
> > version" is not defined in tip's version (f2a4c13).
> 
> I sent https://golang.org/cl/18184 to add some text to "go help
> go.mod".
> 
> Ian
> 
> > On Tue, 2019-06-11 at 17:35 -0700, Ian Lance Taylor wrote:
> > > On Tue, Jun 11, 2019 at 4:53 PM Dan Kortschak 
> > > wrote:
> > > > 
> > > > 
> > > > It would be very nice if the documentation and clarity of
> > > > communication
> > > > around this were improved.
> > > 
> > > I struggle with what to say beyond "it sets the language
> > > version."
> > > Language features available as of that version will be available
> > > for
> > > use.  Language features removed in earlier versions, or added in
> > > later
> > > versions, will not be available.  For almost all users the
> > > default
> > > value will be correct.  At least, I hope that is the case.
> > > 
> > > Ian
> > > 
> 
> 

-- 
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/e22dce014816ce427109b3c2ed6867cd46364614.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go Language Survey

[Michael Jones]

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

On Wed, Jun 12, 2019 at 2:13 PM Michael Jones 
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 
> 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 golang-nuts+unsubscr...@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
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --

*Michael T. jonesmichael.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/CALoEmQw%2BWmrgRWofpcRdAWxzyPg0qYbLNSn5Vt-c1JYJ75dJdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] https://godoc.org/github.com/couchbase/moss

[andrey mirtchovski]

collection is not an exported type:
https://github.com/couchbase/moss/blob/master/collection.go#L24

the ?m=all parameter should enable you to see those, but it's not
working for me on your link. perhaps because "collection" and
"Collection" are not considered by godoc to be two different things?
you may have to file a bug.

here's more info on m=all: https://godoc.org/golang.org/x/tools/cmd/godoc

On Wed, Jun 12, 2019 at 3:25 PM Gert  wrote:
>
> Is it just me or is stuff missing in godoc like for example
>
> // NewBatch returns a new Batch instance with hinted amount of
> // resources expected to be required.
> func (m *collection) NewBatch(totalOps, totalKeyValBytes int) (
> ...
> }
>
> from collection.go
>
> https://godoc.org/github.com/couchbase/moss
>
> --
> 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/fd93525d-f221-4d95-9f20-44dc60308538%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CAK4xykV%3DHSg_7zq0QWZV%3DQiNMADWdiEJGoyezpp9N5KmMiajYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] https://godoc.org/github.com/couchbase/moss

[Gert]

aaa ok thx

On Wednesday, June 12, 2019 at 11:40:29 PM UTC+2, David Anderson wrote:
>
> collection is an unexported type. Godoc doesn't show unexported types by 
> default, so none of the methods of collection will appear.
>
> On Wed, Jun 12, 2019 at 2:25 PM Gert > 
> wrote:
>
>> Is it just me or is stuff missing in godoc like for example
>>
>> // NewBatch returns a new Batch instance with hinted amount of
>> // resources expected to be required.
>> func (m *collection) NewBatch(totalOps, totalKeyValBytes int) (
>> ...
>> }
>>
>> from collection.go
>>
>> https://godoc.org/github.com/couchbase/moss
>>
>> -- 
>> 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/fd93525d-f221-4d95-9f20-44dc60308538%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/9bb9d420-e320-42fd-9b4f-4106ea47982e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Dan Kortschak]

Thanks, Ian.

I'll look later today.

Dan

On Wed, 2019-06-12 at 07:01 -0700, Ian Lance Taylor wrote:
> On Tue, Jun 11, 2019 at 6:30 PM Dan Kortschak 
> wrote:
> > 
> > Having that and exactly what it means in the go help modules output
> > would probably be the best outcome.
> > 
> > Currently it's not mentioned in that output for the current release
> > (1.12.6) and the meaning/implication of "expected [Go] language
> > version" is not defined in tip's version (f2a4c13).
> 
> I sent https://golang.org/cl/18184 to add some text to "go help
> go.mod".
> 
> Ian
> 
> > On Tue, 2019-06-11 at 17:35 -0700, Ian Lance Taylor wrote:
> > > On Tue, Jun 11, 2019 at 4:53 PM Dan Kortschak 
> > > wrote:
> > > > 
> > > > 
> > > > It would be very nice if the documentation and clarity of
> > > > communication
> > > > around this were improved.
> > > 
> > > I struggle with what to say beyond "it sets the language
> > > version."
> > > Language features available as of that version will be available
> > > for
> > > use.  Language features removed in earlier versions, or added in
> > > later
> > > versions, will not be available.  For almost all users the
> > > default
> > > value will be correct.  At least, I hope that is the case.
> > > 
> > > Ian
> > > 
> 
> 

-- 
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/c8e6f134c5b7abc9fd1ad124c86a0ecf115fb903.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] https://godoc.org/github.com/couchbase/moss

[David Anderson]

collection is an unexported type. Godoc doesn't show unexported types by
default, so none of the methods of collection will appear.

On Wed, Jun 12, 2019 at 2:25 PM Gert  wrote:

> Is it just me or is stuff missing in godoc like for example
>
> // NewBatch returns a new Batch instance with hinted amount of
> // resources expected to be required.
> func (m *collection) NewBatch(totalOps, totalKeyValBytes int) (
> ...
> }
>
> from collection.go
>
> https://godoc.org/github.com/couchbase/moss
>
> --
> 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/fd93525d-f221-4d95-9f20-44dc60308538%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAMx%2Br7Va-1QuvUFCvRQuqiyf2S%2BXj0zNUajNEnkES3cSD7Aypw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] https://godoc.org/github.com/couchbase/moss

[Gert]

Is it just me or is stuff missing in godoc like for example

// NewBatch returns a new Batch instance with hinted amount of
// resources expected to be required.
func (m *collection) NewBatch(totalOps, totalKeyValBytes int) (
...
}

from collection.go

https://godoc.org/github.com/couchbase/moss

-- 
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/fd93525d-f221-4d95-9f20-44dc60308538%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Cross-Compile Windows 10 -> FreeBSD

[Tom Mitchell]

Try a VMWARE virtual machine.
Install a FreeBSD distro and as long as the hardware (CPU) is the same you
should be good.
Even targeting a different hardware platform might be easier inside a VM.

Inside the VM you can save temp files and capture compiler, assembler and
linker settings to
Chip away at it all. ABI, API, Libraries, magic numbers.. paths.
https://www.freebsd.org/doc/handbook/linuxemu-advanced.html
ABI and API updates are difficult.
https://www.cyberciti.biz/open-source/freebsd-12-released-here-is-how-to-upgrade-freebsd/

Look with care (including with a debugger) to see what FreeBSD thinks the
new binary is.
Simple things like CR/LF can confuse things.

I see in a FreeBSD (11.2)  to newer FreeBSD (12.0) version update notes.

Installed packages to be REINSTALLED:
sudo-1.8.25p1 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
sqlite3-3.25.1 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
readline-7.0.3_1 (ABI changed: 'freebsd:11:x86:64' -> 
'freebsd:12:x86:64')


Strip nothing,
Minimum optimizations.



On Tue, Jun 11, 2019 at 6:07 PM B Carr  wrote:

> Newb here. I'm in over my head. Using a Win10/amd64 PowerShell with Go
> v1.12.6. Trying to cross-compile
> to FreeBSD/amd64. go env = GOARCH=amd64 & GOOS=freebsd. Source includes
> calls to SQLite3. Compiles
> without errors.
>
> Resulting binary fails on FreeBSD with: "Can't connect to the SQLite DB
> Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work."
>
> Added CGO_ENABLED=1 to the go env.  Recompile fails to build a binary and
> yields this error stream:
>
> "# runtime/cgo
> _cgo_export.c:1:0: error: -fPIC ignored for target (all code is position
> independent) [-Werror]
>  /* Code generated by cmd/cgo; DO NOT EDIT. */
>  ^
> cc1.exe: all warnings being treated as errors"
>
> I have no idea what that means.
>
> Same source compiled for the Win10 machine runs perfectly. If I copy the
> source code over to a
> FreeBSD box with Go installed there and compile, it works fine. It is the
> cross-compilation that
> doesn't seem to work.
>
> This isn't a Go problem, it is something I'm not understanding about
> cross-compiling
>
> Any thoughts?
>
> --
> 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/ebe9fe0d-7727-40b9-bc53-a9d237faecf7%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
   T o mM i t c h e l l

-- 
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/CAAMy4URXSgtj55VTNcRUagX4PAx4s30uT5coxuoJpFBS9t9FKA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go Language Survey

[Michael Jones]

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 
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 golang-nuts+unsubscr...@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
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CALoEmQw3S8TpL9nnqT7yxwRJ%3DOBb3mj4YP_iGJEfUtJqQNx14A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go Language Survey

[Volker Dobler]

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 golang-nuts+unsubscr...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[温博格]

I agree that ? for simple choices is nice. But my C experience with nested
?s and with long expressions for one or both branches has not been nice.
The mandatory {}s make Go's nested ifs more readable (but vertical).

On Wed, Jun 12, 2019 at 2:42 PM Michael Jones 
wrote:

> Roger, here's the same thing, but for Russ's corpus v0.01:
>
> https://gist.github.com/MichaelTJones/609589e05017da4be52bc2810e9df4e8
>
> I've been comparing the two side by side and it's fascinating.
>
> Bakul, more good arguments. I have another motivation in the "?" world
> that I've not argued because it is personal/not general, but a decade ago I
> had two detached retinas, surgeries, and imperfect recovery. Part of my
> vision that I lost is just below the center...maybe -15 degrees to -40
> degrees. The brain knows when I want to see things things there and moves
> the eyes around to gather that part of the visual field. This "hunting" is
> tiring of the muscles and causes issues. left-to-right density is easy for
> me, vertical is very bad. Your:
>
> x := b? 2 : 1
>
> is instantaneous, a sight read; while the:
>
> var x int
> if b {
>   x = 2
> } else {
>   x = 1
> }
>
> and
>
> x := 1
> if b {
>   x = 2
> }
>
> ...feel like climbing Everest. It is hard to explain the difficulty.
> Fortunately it is not a widespread problem. Certainly not Go's problem, but
> I'd pay double for a "wide" mode where gofmt tolerated "var x int; if b { x
> = 2 } else { x = 1 }". In fact, now that i've just seen this, I am going
> to make a local version and hook it to vs code. Why did I not think of this
> before! Wow.
>
> On Wed, Jun 12, 2019 at 9:24 AM Bakul Shah  wrote:
>
>> On Jun 12, 2019, at 8:24 AM, Michael Jones 
>> wrote:
>> >
>> > Bakul, these are good points.
>> >
>> > On the second, I used to always write (C/C++):
>> >
>> > If (things are good) {
>> > happy case
>> > } else {
>> > sad case
>> > }
>> >
>> > so the nesting was that the all-good was the first code block even when
>> multiply nested and the exceptions came later. A blunt kind of literate
>> programming that wants to talk about the 99% case first and the weird
>> things later. In Go I've converted to talk about problems all the way to
>> the bitter end and then when you run out of problems, do the job. Now that
>> you point it out, "else" falls by the wayside in this situation because it
>> is else when you did not return already. Each Go-style if-err-die "clause"
>> is consuming an else. Thank you. I had not thought of it so clearly.
>>
>> It's just a different style. Here you are chopping off "sad cases" until
>> you are left with the big fat happy case! And by returning ASAP for the
>> sad cases, you reduce indentation quite a bit, which helps readability.
>>
>> >
>> > The first is a good point too. The debate about the ternary operator
>> might be better viewed as a completion of short variable declaration. Block
>> scope means is not possible to write...
>> >
>> > if b {
>> > x := 1
>> > } else {
>> > x := 2
>> > }
>> > :
>> > use X
>> >
>> > ...so the benefits of short variable declaration are lost to a choice
>> between redundancy as you show:
>> >
>> > x := 1
>> > if b {
>> > x = 2
>> > }
>> >
>> > which hides the intent -- the if b is the intent and that's not evident
>> from x := 1. The intent is "x := either 1 or 2 depending" and that is well
>> expressible only when the := is in the outer scope and the "1 or 2" are
>> expressions from an inner one being transported across the lexical boundary
>> by an operator -- the "depending" operator whatever its name or form might
>> be.
>>
>> You can almost speed-read straight line code but as soon as you
>> encounter if or switch (or other control flow changing part) you
>> have to stop and regroup. This is why (for me)
>>
>> x := b? 2 : 1
>>
>> is far easier to read than either
>>
>> var x int
>> if b {
>>   x = 2
>> } else {
>>   x = 1
>> }
>>
>> or worse,
>>
>> x := 1
>> if b {
>>   x = 2
>> }
>>
>>
>> > x := {1,2}[b]
>>
>> This requires evaluating both alternatives. This may not
>> even be possible:
>>
>> x := p == nil? 10 : p.val
>>
>> or may had extra side-effects:
>>
>> x := {f1(), f2()}[b]
>>
>> This can also a problem with
>>
>> x := f1()
>> if b { x = f2() }
>>
>>
>>
>>
>
> --
>
> *Michael T. jonesmichael.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/CALoEmQw10H-t1GdVG_PDxiPVtaUGJ3uvsBUXyt6adMiPOAAnow%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google 

Re: [go-nuts] cgo behaviour change between go1.11.10 and go1.12.5

[Neil Schellenberger]

Sorry for the delay in responding.  Filed as
https://github.com/golang/go/issues/32579.

On Tue, Jun 11, 2019 at 1:21 AM Ian Lance Taylor  wrote:

> On Mon, Jun 10, 2019 at 9:14 PM Neil Schellenberger
>  wrote:
> >
> > When upgrading our build container from 1.11.10 to 1.12.5, some of our
> tests failed in a surprising way.  I've boiled down the issue to this short
> example code fragment.
> >
> > package main
> >
> > // #include 
> > // struct S { unsigned char data[18]; };
> > import "C"
> > import "unsafe"
> >
> > func main() {
> > var array [5]C.struct_S
> > for i := range array {
> > C.memset(unsafe.Pointer([i].data[0]), 0xff, C.sizeof_struct_S)
> > }
> > for i := range array {
> > for j := range array[i].data {
> > if array[i].data[j] != C.uchar(0xff) {
> > panic("oops")
> > }
> > }
> > }
> > }
> >
> > Under 1.11 this runs to completion; under 1.12 it panics.
> >
> > Debugging and instrumenting shows that the problem is the first argument
> to memset is not what one would expect when run under 1.12.  (The address
> of a heap temporary copy rather than the original perhaps?)
> >
> > Strangely, either parenthesising the argument expression to the address
> operand ("&(array[i].data[0])") or removing the final index expression
> ("[i].data") "fixes" the problem.
> >
> > I've spelunked through the AST (identical under both); the liveness and
> escape analysis (different); the parse tree (different); and the go asm
> (different).  Frankly, my gc-fu is very weak and I don't really know what
> I'm looking for.
> >
> > I assume that the root cause is that we were violating some sort of
> liveness or escape policy, but I can't figure out what it would be (or why
> minor syntactic changes "fix" things).  I'd be quite curious to know.
> >
> > The workaround in the real code is simple, so this isn't a huge issue,
> just a a bit of a mystery.
>
> It's a bug.  Would you mind opening an issue with this test case at
> https://golang.org/issue?  Thanks.
>
> Ian
>

-- 
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/CAM3gH5_3By%2B37NxrvarWqTw3h-aAuC4owyJnELhpE%3DDcQJhMLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[Michael Jones]

Roger, here's the same thing, but for Russ's corpus v0.01:

https://gist.github.com/MichaelTJones/609589e05017da4be52bc2810e9df4e8

I've been comparing the two side by side and it's fascinating.

Bakul, more good arguments. I have another motivation in the "?" world that
I've not argued because it is personal/not general, but a decade ago I had
two detached retinas, surgeries, and imperfect recovery. Part of my vision
that I lost is just below the center...maybe -15 degrees to -40 degrees.
The brain knows when I want to see things things there and moves the eyes
around to gather that part of the visual field. This "hunting" is tiring of
the muscles and causes issues. left-to-right density is easy for me,
vertical is very bad. Your:

x := b? 2 : 1

is instantaneous, a sight read; while the:

var x int
if b {
  x = 2
} else {
  x = 1
}

and

x := 1
if b {
  x = 2
}

...feel like climbing Everest. It is hard to explain the difficulty.
Fortunately it is not a widespread problem. Certainly not Go's problem, but
I'd pay double for a "wide" mode where gofmt tolerated "var x int; if b { x
= 2 } else { x = 1 }". In fact, now that i've just seen this, I am going to
make a local version and hook it to vs code. Why did I not think of this
before! Wow.

On Wed, Jun 12, 2019 at 9:24 AM Bakul Shah  wrote:

> On Jun 12, 2019, at 8:24 AM, Michael Jones 
> wrote:
> >
> > Bakul, these are good points.
> >
> > On the second, I used to always write (C/C++):
> >
> > If (things are good) {
> > happy case
> > } else {
> > sad case
> > }
> >
> > so the nesting was that the all-good was the first code block even when
> multiply nested and the exceptions came later. A blunt kind of literate
> programming that wants to talk about the 99% case first and the weird
> things later. In Go I've converted to talk about problems all the way to
> the bitter end and then when you run out of problems, do the job. Now that
> you point it out, "else" falls by the wayside in this situation because it
> is else when you did not return already. Each Go-style if-err-die "clause"
> is consuming an else. Thank you. I had not thought of it so clearly.
>
> It's just a different style. Here you are chopping off "sad cases" until
> you are left with the big fat happy case! And by returning ASAP for the
> sad cases, you reduce indentation quite a bit, which helps readability.
>
> >
> > The first is a good point too. The debate about the ternary operator
> might be better viewed as a completion of short variable declaration. Block
> scope means is not possible to write...
> >
> > if b {
> > x := 1
> > } else {
> > x := 2
> > }
> > :
> > use X
> >
> > ...so the benefits of short variable declaration are lost to a choice
> between redundancy as you show:
> >
> > x := 1
> > if b {
> > x = 2
> > }
> >
> > which hides the intent -- the if b is the intent and that's not evident
> from x := 1. The intent is "x := either 1 or 2 depending" and that is well
> expressible only when the := is in the outer scope and the "1 or 2" are
> expressions from an inner one being transported across the lexical boundary
> by an operator -- the "depending" operator whatever its name or form might
> be.
>
> You can almost speed-read straight line code but as soon as you
> encounter if or switch (or other control flow changing part) you
> have to stop and regroup. This is why (for me)
>
> x := b? 2 : 1
>
> is far easier to read than either
>
> var x int
> if b {
>   x = 2
> } else {
>   x = 1
> }
>
> or worse,
>
> x := 1
> if b {
>   x = 2
> }
>
>
> > x := {1,2}[b]
>
> This requires evaluating both alternatives. This may not
> even be possible:
>
> x := p == nil? 10 : p.val
>
> or may had extra side-effects:
>
> x := {f1(), f2()}[b]
>
> This can also a problem with
>
> x := f1()
> if b { x = f2() }
>
>
>
>

-- 

*Michael T. jonesmichael.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/CALoEmQw10H-t1GdVG_PDxiPVtaUGJ3uvsBUXyt6adMiPOAAnow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Yet another new fast json/xml parser library

[roger peppe]

I haven't looked further than the godoc, but a couple of initial
suggestions:

- the word JSON should always be spelled in all-caps if the first letter is
J, so you would be better with NewJSONParser.

- you should almost certainly return a chan, not a pointer to chan.


On Tue, 11 Jun 2019, 13:47 Tamer,  wrote:

> Hello everyone,
>
> I have developed a new json parser library. It is similar jstream library
> but it allows stream over selected json member instead of depth. It also
> allow skipping json members for less memory usage.
>
> https://github.com/tamerh/jsparser
>
> I have also refactored previously developed xml parser with similar
> approach.
>
> https://github.com/tamerh/xml-stream-parser
>
> Please let know if you have suggestions/feedbacks.
>
> Cheers
> Tamer
>
> --
> 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/22eef643-66bf-451e-ba84-1eb968682aea%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAJhgachf%2By5r_6EyXJBickrn9GEEscmr8reo18%2BFQW2Zey_vxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Proposal: disallow "fall through" to a labeled statement #32565

[Kurtis Rader]

On Wed, Jun 12, 2019 at 1:18 AM Jan Mercl <0xj...@gmail.com> wrote:

> > Disallowing unintended fall throughs into labeled sections of a block
> will prevent a class of stupid errors.
>
> I'm stupid and I know it. Yet, it seems I haven't made this kind of error
> in the last ten years of Go. Maybe I'm just lucky. Or maybe this kind of
> error is rare. But if it's rare then a language change preventing it is
> questionable as the improvements would be also rare.
>
> Are there any statistics available about how many times people run into
> this class of bugs?
>

I've been trying to drag the AST/ksh code (written in C) into the 21st
century for the past two years. It contains more goto's and associated
labels per 1KLOC than any code base I've worked on in the past four
decades. I can recall fixing just one bug of this type (i.e., unintended
fallthru to a labeled block) in this project. I can't recall dealing with
any other instances in the  four decades I've been programming. So my
anecdotal experience is that this class of error is exceedingly rare.

Note that this class of bugs is distinct from that caused by C's default of
case blocks falling thru to the next case block if you don't explicitly
break from the block. A feature that does cause lots of bugs. Fortunately
the designers of Go broke from C tradition in this regard.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD-bChqXC-%2BEJdV%2BO%3DWwCrRkgBtgbZRFBZvfx5CF7-CTNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[Bakul Shah]

On Jun 12, 2019, at 8:24 AM, Michael Jones  wrote:
> 
> Bakul, these are good points.
> 
> On the second, I used to always write (C/C++):
> 
> If (things are good) {
> happy case
> } else {
> sad case
> }
> 
> so the nesting was that the all-good was the first code block even when 
> multiply nested and the exceptions came later. A blunt kind of literate 
> programming that wants to talk about the 99% case first and the weird things 
> later. In Go I've converted to talk about problems all the way to the bitter 
> end and then when you run out of problems, do the job. Now that you point it 
> out, "else" falls by the wayside in this situation because it is else when 
> you did not return already. Each Go-style if-err-die "clause" is consuming an 
> else. Thank you. I had not thought of it so clearly.

It's just a different style. Here you are chopping off "sad cases" until
you are left with the big fat happy case! And by returning ASAP for the
sad cases, you reduce indentation quite a bit, which helps readability.

> 
> The first is a good point too. The debate about the ternary operator might be 
> better viewed as a completion of short variable declaration. Block scope 
> means is not possible to write...
> 
> if b {
> x := 1
> } else {
> x := 2
> }
> :
> use X
> 
> ...so the benefits of short variable declaration are lost to a choice between 
> redundancy as you show:
> 
> x := 1
> if b {
> x = 2
> }
> 
> which hides the intent -- the if b is the intent and that's not evident from 
> x := 1. The intent is "x := either 1 or 2 depending" and that is well 
> expressible only when the := is in the outer scope and the "1 or 2" are 
> expressions from an inner one being transported across the lexical boundary 
> by an operator -- the "depending" operator whatever its name or form might be.

You can almost speed-read straight line code but as soon as you
encounter if or switch (or other control flow changing part) you
have to stop and regroup. This is why (for me)

x := b? 2 : 1

is far easier to read than either

var x int
if b {
  x = 2
} else {
  x = 1
}

or worse,

x := 1
if b {
  x = 2
}


> x := {1,2}[b]

This requires evaluating both alternatives. This may not
even be possible:

x := p == nil? 10 : p.val

or may had extra side-effects:

x := {f1(), f2()}[b]

This can also a problem with

x := f1()
if b { x = f2() }



-- 
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/94BE2E16-59A0-4984-8D47-E2D3B28E6C98%40bitblocks.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Cross-Compile Windows 10 -> FreeBSD

[B Carr]

Thank you. Probably too hard for me.

On Tuesday, June 11, 2019 at 10:09:49 PM UTC-6, Tamás Gulácsi wrote:
>
> Not hopeless, just hard. You need a cross-C-compiler, and use that.
>
> It's easier to compile on native en.
> But you can try github.com/karalabe/xgo if you have Docker.
>

-- 
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/6e7cc795-341b-4c9b-8bb9-7b388ae94aee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[Lucio]

On Wednesday, 12 June 2019 17:25:19 UTC+2, Michael Jones wrote:
>
> Bakul, these are good points.
>
>
> Nice work, Michael; nice comments, Bakul.

It's nice when the philosophy behind intuition is given some solidity. I 
keep hoping to see more of Dijkstra's "A Discipline of Programming" leaking 
into the Go psyche, but there have been a few too many diversions that may 
never be reversed.

Personally, I see exactly zero benefit in x++ or x--, now that these are 
more clearly represented as x += 1 and x -= 1. I have discarded them from 
my idioms. But that's just me. I'm hoping no one will find it necessary to 
edit my code to correct this :-).

Lucio.

-- 
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/caf98fc1-b371-4b6a-baef-62cf078d6a9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[roger peppe]

I wonder whether the Go 1.13 code base is representative of Go in the wild.
It might be interesting to see the results when run on the code in the Go
corpus. https://github.com/rsc/corpus

On Wed, 12 Jun 2019 at 14:08, 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. jonesmichael.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/CALoEmQzK3v4V%2BRYWZorfX0Nst%2BOXwzP9e51mCDm2ri-4jfzXyA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAJhgachZMnWJYv2Qe33rWTpQZJsgz6r3un1Dq2vcv2Pz_ENNFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[Michael Jones]

Bakul, these are good points.

On the second, I used to always write (C/C++):

If (things are good) {
happy case
} else {
sad case
}


so the nesting was that the all-good was the first code block even when
multiply nested and the exceptions came later. A blunt kind of literate
programming that wants to talk about the 99% case first and the weird
things later. In Go I've converted to talk about problems all the way to
the bitter end and then when you run out of problems, do the job. Now that
you point it out, "else" falls by the wayside in this situation because it
is else when you did not return already. Each Go-style if-err-die "clause"
is consuming an else. Thank you. I had not thought of it so clearly.

The first is a good point too. The debate about the ternary operator might
be better viewed as a *completion* of short variable declaration. Block
scope means is not possible to write...

if b {
x := 1
} else {
x := 2
}
:
use X

...so the benefits of short variable declaration are lost to a choice
between redundancy as you show:

x := 1
if b {
x = 2
}

which hides the intent -- the if b is the intent and that's not evident
from x := 1. The intent is "x := either 1 or 2 depending" and that is well
expressible only when the := is in the outer scope and the "1 or 2" are
expressions from an inner one being transported across the lexical boundary
by an operator -- the "depending" operator whatever its name or form might
be.

The pro-? forces might better petition under the "make short assignments
complete" banner.

x := if b {1} else {2}
x := switch b {case true: 1; case false: 2}
x := b ? 1 : 2

or, my dream scenario, which is just a dream because of too many moving
parts to sell all at once:

allow bool to int/uint casting with obvious meaning T=>1, F=>0
allow "implicit" types in literal definitions like this:

x := {1,2}[int(b)]

...or even if one could dare hope for automatic coercion of the harmless
bool...

x := {1,2}[b]

as in

workers := {runtime.NumCPU(),1}[*ParallelMode]

...oh to dream.



On Wed, Jun 12, 2019 at 7:56 AM Bakul Shah  wrote:

> On Jun 12, 2019, at 7:36 AM, Michael Jones 
> wrote:
> >
> > 128640 If statements, and just 8034 else, a 16:1 ratio. I'd like to
> understand this better,
>
> There are two patterns that encourage this:
>
> x := v1
> if someCond { x = v2 }
>
> And
>
> if someCond { return ... }
>
> The second pattern acts sort of as a filter. Which is useful (fewer
> choices left).
>
> The first pattern is due to a lack of C’s ?: construct. [In light of that
> it is amusing to see try as a “function” being proposed that even does a
> conditional return!]
>


-- 

*Michael T. jonesmichael.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/CALoEmQw5xCLMFj2k9exBBuvr0SBL2zifZoUER0tmiViyGWJt0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[Bakul Shah]

On Jun 12, 2019, at 7:36 AM, Michael Jones  wrote:
> 
> 128640 If statements, and just 8034 else, a 16:1 ratio. I'd like to 
> understand this better,

There are two patterns that encourage this:

x := v1
if someCond { x = v2 }

And

if someCond { return ... }

The second pattern acts sort of as a filter. Which is useful (fewer choices 
left).

The first pattern is due to a lack of C’s ?: construct. [In light of that it is 
amusing to see try as a “function” being proposed that even does a conditional 
return!]

-- 
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/44D09A2F-CCC7-492D-B06C-6D870E225283%40bitblocks.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[t hepudds]

Hi Ian,

Thank you for sending that CL 181840. 

One minor request for clarification on the discussion here. 

When you said earlier in this thread:

> “For almost all users the default
value will be correct.  At least, I hope that is the case.”

I *think* what you are saying is for almost everyone the default value set 
should be a valid choice when initially selected by the 'go’ command, even 
though someone might later need to manually change it in the future as new 
language features are released?

In other words, if hypothetically something like a new 'try' keyword lands in 
something like Go 1.15, then at that point someone might need to change the 
value in their go.mod from for example 'go 1.12'  to instead read 'go 1.15' if 
they want to use the new language feature?

Sorry if that is not correct.

Regards,
thepudds

-- 
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/39cd7ecc-501c-4eaa-8a00-cbd2a0fae328%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[Michael Jones]

Yes, quite a bit there of note:

More hex numbers than decimal. That was a surprise.

The "0o" prefixed octal number literals just went in in the last two days.
I think a gofix rewrite might be in order--it is more explicit and less
vulnerable to mistake than the legacy 0377 style--despite a whole career of
the other from the PDP-8 onward.

128640 If statements, and just 8034 else, a 16:1 ratio. I'd like to
understand this better, but my test is just a lexer and not a parser so I
don't have much context to draw conclusions about this specifically.
However it seems such a huge ratio that switch must be carrying the load.
There are 5024 switch statements and 24903 cases, so that's "4 virtual
elses" per switch in some broad sense.

Type is well used. 2x as much as struct, so even if half are "type X struct
{...}" the other half are not.

The import frequency is not interpretable beyond "every package imports
something" because of the inner list in imports as typically written and
that's available to a parser but not at the lexical level. I could hack it
to look at lines between the parens after import, but that's beyond the
"test the lexer" goal.

The default to switch ratio is high, and there is at most one per, so this
means 60% of switch statements have a default, or by extension, express
if-then-else if-else-if-else logic with a final clauseless else.

Few fallthrough statements and that's natural. There were few cases outside
Duff's Device where C/C++ code is allowed to fall through by default.
[Having just written a lexer, I can share that would I think be much better
than the switch's fallthrough would be a way to say, "now that I'm in this
case, I've changed my mind and want to PROCEED with the case testing
starting with the next case." That would be swell and there is no way to do
it.)

Byte by that name is quite popular compared to its other identity, uint8.
[Opinion: never have been comfortable about this one. There are no living
machines with non 8-bit bytes, so the generality of "byte is the natural
size for a byte" is a stretch here, as would be 1 for the size of a bit.]

Using true is almost 3x false. I wonder if that is natural or if the
default value of zero/false is behind it.

Lots of panics and not many recovers.

Operators are interesting. nearly 2.5x the != than ==. Perhaps "err != nil"
is the story. A lot more < than >, which is curious...presumably from for
loops, but can't tell at the token level. Way more left shifts than right.
Not true in my own code, so interesting. Some disjunctive/conjunctive
dissonance: 3x the && as ||. 7 x the ++ as --. I guess people like to count
up, even when counting down has the advantage of the expensive load being
done once and the test being against zero. 5x += than -=, surprising.
Pretty low incidence of &^ and &^=, not true in my code at all, so I
suppose the BIC "Bit Clear" of PDP-11 is not a meme. That's surprising to
me: a|=b, sets the b bits in a, a&^b, clears the b bits in a. They are a
team, yet | is  50x the usage of &^. Maybe because C did not have it and
C++ copied and Java copied and people have not understood? These should be
peers. /= is not popular, and %= even less so. I use them both but I may be
the only one (there is some code like this in Big from way back.)

External references shows that the Go team writes lots of tests, and that
unsafe is wildly popular.

The most popular character constant is '0' 3x '9' so it's not all ('0' <=
ch && ch <= '9') ... there are some extra '0's in there.

On Wed, Jun 12, 2019 at 6:49 AM Ian Lance Taylor  wrote:

> On Wed, Jun 12, 2019 at 6:08 AM 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
>
> Pretty interesting.  Thanks.
>
> I note that "goto" is more common than "select".  That has to be an
> artifact of the code base.
>
> Ian
>


-- 

*Michael T. jonesmichael.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 

Re: [go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Ian Lance Taylor]

On Tue, Jun 11, 2019 at 6:30 PM Dan Kortschak  wrote:
>
> Having that and exactly what it means in the go help modules output
> would probably be the best outcome.
>
> Currently it's not mentioned in that output for the current release
> (1.12.6) and the meaning/implication of "expected [Go] language
> version" is not defined in tip's version (f2a4c13).

I sent https://golang.org/cl/18184 to add some text to "go help go.mod".

Ian

> On Tue, 2019-06-11 at 17:35 -0700, Ian Lance Taylor wrote:
> > On Tue, Jun 11, 2019 at 4:53 PM Dan Kortschak 
> > wrote:
> > >
> > >
> > > It would be very nice if the documentation and clarity of
> > > communication
> > > around this were improved.
> > I struggle with what to say beyond "it sets the language version."
> > Language features available as of that version will be available for
> > use.  Language features removed in earlier versions, or added in
> > later
> > versions, will not be available.  For almost all users the default
> > value will be correct.  At least, I hope that is the case.
> >
> > Ian
> >

-- 
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/CAOyqgcVM3kos_7hQ7B_d2vKWF%2BvFOqQb9s00fxBcxQ6QhefrFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[Ian Lance Taylor]

On Wed, Jun 12, 2019 at 6:08 AM 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

Pretty interesting.  Thanks.

I note that "goto" is more common than "select".  That has to be an
artifact of the code base.

Ian

-- 
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/CAOyqgcUF%2BPLhiA5Fs4fmrL-PCreq9NVt6YzO1O-Sc9CO7Y6h6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Go Language Survey

[Michael Jones]

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. jonesmichael.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/CALoEmQzK3v4V%2BRYWZorfX0Nst%2BOXwzP9e51mCDm2ri-4jfzXyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: How to control go routine numbers in function call

[Jesper Louis Andersen]

And if you prefer a talk, there is one by Bryan C. Mills,

https://www.youtube.com/watch?v=5zXAHh5tJqQ

which describes common concurrency patterns and how to apply them. In your
case, a buffered channel can work as a (counting) semaphore. The invariant
is: the number of tokens in the channel is the number of currently active
workers. If the channel is full and you block, all worker slots are
occupied. As workers complete, they remove a token from the channel, making
room for another worker.

Finalization is important. You end by _filling_ the semaphore with tokens.
These tokens have no workers associated with them, but are "virtual dummy
sentinels" in a sense. Once the channel is full of these sentinel tokens,
all the real workers must have exited, so you can go on[0]. You can also
see this as vacant seats in a restaurant, say. As the restaurant wants to
close, it starts filling up the seats with bulbasaurs. Once all seats have
bulbasaurs in them, the restaurant can close.

[0] The section is at https://youtu.be/5zXAHh5tJqQ?t=1902 but the whole
talk is definitely worth it.


On Sat, Jun 8, 2019 at 8:25 AM Krzysztof Kowalczyk 
wrote:

> See
> https://www.programming-books.io/essential/go/limiting-concurrency-with-a-semaphore-26ac6084d7404f7385e4eccaa3fd20de
>  for
> one way that uses a channel as a semaphore to limit concurrency.
>
> On Friday, June 7, 2019 at 6:28:01 PM UTC-7, Joseph Wang wrote:
>>
>> Hi everyone
>>
>> I have a simple question about go routines.
>>
>> So I have a function like this
>>
>> Func1() {
>>
>>   for n := range array {
>> go fun2()
>>   }
>> }
>>
>> So as I can not make sure array has a fix size, then I cannot control go
>> routines number. Does any one have some elegant ways that I can limit this
>> function1 create fix number go routines?
>>
>> Best
>>
>> Joseph
>>
> --
> 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/ceb52644-b7a7-4ab1-aa74-dd5b60fbd55c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
J.

-- 
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/CAGrdgiWDF1eB4D_9U9k9sTm-PVbJKaYABeL%3D4H_jDk4EUbY%3DUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Proposal: disallow "fall through" to a labeled statement #32565

[Jan Mercl]

> Disallowing unintended fall throughs into labeled sections of a block
will prevent a class of stupid errors.

I'm stupid and I know it. Yet, it seems I haven't made this kind of error
in the last ten years of Go. Maybe I'm just lucky. Or maybe this kind of
error is rare. But if it's rare then a language change preventing it is
questionable as the improvements would be also rare.

Are there any statistics available about how many times people run into
this class of bugs?

The linked motivation example at
https://golang.org/src/cmd/compile/internal/gc/typecheck.go?h=goto+ret#L3800
 can be easily refactored to have no gotos and no labels at all. I'd say
it's not a typical piece of Go code. I guess it's the original C compiler
code translated mechanically to Go, isn't it? BTW: Should I send a CL?

PS: Full disclosure - I think we should mostly keep the language alone. Any
tiny change makes the surface of the language a tiny bit larger. But there
are _tons_ of proposed language changes at the issue tracker and those tiny
changes just add quickly. Also, even though not protected by the
compatibility promise, almost every language change breaks an unknown
number of tools people wrote in a decade. Only language changes enabling
what cannot be done by other means should be considered, IMHO.

-- 
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/CAA40n-V%3DQo9SLioE%3D36QbAbV74vh0tuN3VQh0KZCgW7f-axdwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.