Re: [go-nuts] retaining mapiterkey return values in *reflect.MapIter

2020-06-30 Thread 'Dan Kortschak' via golang-nuts 
Looking again, the second part of my question was wrong (it is a call
to `mapiterkey` and then `mapiterelem` in `Value`).

The code for Key and Value are almost identical, so the question
whether to send a change boils down whether the similarity between the
two is a benefit or a cost. I'm actually leaning towards the similarity
being a benefit and one that would be broken by retaining the value.

Dan

On Tue, 2020-06-30 at 19:24 -0700, Ian Lance Taylor wrote:
> On Tue, Jun 30, 2020 at 6:39 PM 'Dan Kortschak' via golang-nuts
>  wrote:
> > 
> > Is there a reason not to retain the returned value from
> > `mapiterkey` on
> > line 1243 of reflect/value.go[1] for use on line 1249[2].
> > 
> > ```
> > // Key returns the key of the iterator's current map entry.
> > func (it *MapIter) Key() Value {
> > if it.it == nil {
> > panic("MapIter.Key called before Next")
> > }
> > if mapiterkey(it.it) == nil { //L1243
> > panic("MapIter.Key called on exhausted iterator")
> > }
> > 
> > t := (*mapType)(unsafe.Pointer(it.m.typ))
> > ktype := t.key
> > return copyVal(ktype, it.m.flag.ro()|flag(ktype.Kind()),
> > mapiterkey(it.it)) // L1249
> > }
> > ```
> > 
> > The same question applies to `*MapIter.Value` method just below
> > `Key`.
> 
> I don't think there is any reason to call the function twice.  The
> value could be retained.
> 
> I think the functionswill be inlined, so it probably won't make any
> performance difference, but it might be a little clearer.
> 
> 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/6a06fb0b70927f05ed2680e11953e28af50f5a16.camel%40kortschak.io.

Re: [go-nuts] retaining mapiterkey return values in *reflect.MapIter

2020-06-30 Thread Ian Lance Taylor 
On Tue, Jun 30, 2020 at 6:39 PM 'Dan Kortschak' via golang-nuts
 wrote:
>
> Is there a reason not to retain the returned value from `mapiterkey` on
> line 1243 of reflect/value.go[1] for use on line 1249[2].
>
> ```
> // Key returns the key of the iterator's current map entry.
> func (it *MapIter) Key() Value {
> if it.it == nil {
> panic("MapIter.Key called before Next")
> }
> if mapiterkey(it.it) == nil { //L1243
> panic("MapIter.Key called on exhausted iterator")
> }
>
> t := (*mapType)(unsafe.Pointer(it.m.typ))
> ktype := t.key
> return copyVal(ktype, it.m.flag.ro()|flag(ktype.Kind()), 
> mapiterkey(it.it)) // L1249
> }
> ```
>
> The same question applies to `*MapIter.Value` method just below `Key`.

I don't think there is any reason to call the function twice.  The
value could be retained.

I think the functionswill be inlined, so it probably won't make any
performance difference, but it might be a little clearer.

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/CAOyqgcUWyV5SHi9pw2n-jFJ%3D-e2dLcUqfNz2pJgL%2BkvwyR4tCA%40mail.gmail.com.

[go-nuts] retaining mapiterkey return values in *reflect.MapIter

2020-06-30 Thread 'Dan Kortschak' via golang-nuts 
Is there a reason not to retain the returned value from `mapiterkey` on
line 1243 of reflect/value.go[1] for use on line 1249[2].

```
// Key returns the key of the iterator's current map entry.
func (it *MapIter) Key() Value {
if it.it == nil {
panic("MapIter.Key called before Next")
}
if mapiterkey(it.it) == nil { //L1243
panic("MapIter.Key called on exhausted iterator")
}

t := (*mapType)(unsafe.Pointer(it.m.typ))
ktype := t.key
return copyVal(ktype, it.m.flag.ro()|flag(ktype.Kind()), 
mapiterkey(it.it)) // L1249
}
```

The same question applies to `*MapIter.Value` method just below `Key`.

thanks
Dan

[1]
https://github.com/golang/go/blob/96e83664378918980bd8f60822c4bc39befcb668/src/reflect/value.go#L1243
[2]
https://github.com/golang/go/blob/96e83664378918980bd8f60822c4bc39befcb668/src/reflect/value.go#L1249


-- 
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/c9e63667e67228e2486460d1e79aa01568b633d3.camel%40kortschak.io.

Re: [go-nuts] draft design for // +build replacement

2020-06-30 Thread Sam Whited 
I agree. I like the filename based constraints, but having both is
annoying and since the comment based constraints are more flexible I
think they'd have to be the ones to stay. I frequently find myself
looking for constraints by grepping for whatever it is I want, but if I
have filename based constraints I have to do a find as well. Having one
or another but not both would make my life easier in a small but
meaningful way.

—Sam

On Tue, Jun 30, 2020, at 18:56, roger peppe wrote:
> One thing I'd really like to see is the eventual deprecation of filename-
> based build constraints (e.g. file_linux.go). They make it hard for
> users (not everyone knows the name of all architectures), hard for
> tooling (tools need to maintain a list of current architectures) and
> potentially compatibility-breaking (adding a new architecture can
> change the meaning of existing files). Could we eventually mandate in-
> file build constraints instead?

-- 
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/09cfada5-0e6d-4e0b-9d63-6e5963530a42%40www.fastmail.com.

Re: [go-nuts] draft design for // +build replacement

2020-06-30 Thread ben...@gmail.com 
FWIW, I *like* the filename-based constraints. I can look at the source for 
the OS package (https://golang.org/src/os/) and immediately go to the 
_windows.go files to see how they do things on Windows (for example). It's 
really obvious from the directory listing, and I don't have to dig into the 
files to see what the build constraint is.

Then again, if Go got rid of filename-based constraints, people could still 
name their files like that for visibility purposes, but the actual build 
constraint would be in "// +build" or "//go:build" rules in the file itself.

-Ben

One thing I'd really like to see is the eventual deprecation of 
>>> filename-based build constraints (e.g. file_linux.go).
>>> They make it hard for users (not everyone knows the name of all 
>>> architectures), hard for tooling (tools
>>> need to maintain a list of current architectures) and potentially 
>>> compatibility-breaking (adding
>>> a new architecture can change the meaning of existing files). Could we 
>>> eventually mandate
>>> in-file build constraints instead?
>>>
>>

-- 
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/82154e18-c273-4969-8a8c-f7a04dda5109n%40googlegroups.com.

Re: [go-nuts] draft design for // +build replacement

2020-06-30 Thread 'Axel Wagner' via golang-nuts 
Hm, though I guess in terms of compatibility, it should be mentioned that
according to the design, this currently valid program wouldn't build at
go1.(N-1) (and later, unless the `foo` build tag is specified):
https://play.golang.org/p/436NUYC7rno
If that's okay, then maybe mandating build tags is too?

On Wed, Jul 1, 2020 at 1:35 AM Axel Wagner 
wrote:

> On Wed, Jul 1, 2020 at 1:10 AM roger peppe  wrote:
>
>> LGTM. This is a welcome change. I often need to look up how to spell
>> "// +build" currently :)
>>
>> One thing I'd really like to see is the eventual deprecation of
>> filename-based build constraints (e.g. file_linux.go).
>> They make it hard for users (not everyone knows the name of all
>> architectures), hard for tooling (tools
>> need to maintain a list of current architectures) and potentially
>> compatibility-breaking (adding
>> a new architecture can change the meaning of existing files). Could we
>> eventually mandate
>> in-file build constraints instead?
>>
>
> I think *mandating* this could be considered a backwards incompatible
> change (the only real counter-argument is that it's "just tooling"). AIUI,
> Russ' design doesn't actually remove `// +build` for this reason, but only
> deprecates it with automatic re-writing.
> Of course, nothing would prevent us from doing the same - deprecating
> purely filename-based constraints and have `gofmt` actively add build tags.
> Note that the filenames wouldn't go away anyways; you still need separate
> files, so you still need separate names. You wouldn't need *these specific*
> names, but you'd probably end up with very similar ones.
>
> If you'd indeed suggest removing file name based constraints altogether,
> I'd argue that it should probably happen in this same process (not
> "eventually" :) ) - it involves touching ~every Go package with constraints
> anyway, so having to only do this once would probably be preferable.
>
>
>>
>>   cheers,
>> rog.
>>
>>
>> On Tue, 30 Jun 2020 at 21:04, Russ Cox  wrote:
>>
>>> Hi all,
>>>
>>> I've posted a draft design for replacing // +build lines with //go:build
>>> lines that support standard boolean expression syntax. It is a draft design
>>> I'm circulating for feedback, not an official proposal. (I certainly hope
>>> it will be well received and can be made into a proposal, but that's not
>>> where we are today.)
>>>
>>> If you are interested, there is a doc and a video, linked below. As an
>>> experiment, I'd like to try using Reddit for the discussion, also linked
>>> below. The idea is that proper threading support should scale better than
>>> GitHub or a single large mail thread here would. But for those who don't do
>>> Reddit, I will keep an eye on this thread and reply as best I can.
>>>
>>> Video: https://golang.org/s/go-build-video
>>> Design: https://golang.org/s/go-build-design
>>> Q: https://golang.org/s/go-build-reddit
>>>
>>> Thanks!
>>>
>>> Best,
>>> Russ
>>>
>>> --
>>> 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/CAA8EjDTO1NX%3DacOTqEfD%3D6pumUWzNNcGO%2BsPMrQVYdO0cmWsvQ%40mail.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/CAJhgacjXjt%2BhKVOLadcRxvwMnWRMJS%2BPwnKt8GdCa%2Bc77GUmRQ%40mail.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/CAEkBMfFxsC1L48UZXu4fbP6zJqQUg-JxAaE0JPdmQwZTLoET6Q%40mail.gmail.com.

Re: [go-nuts] draft design for // +build replacement

2020-06-30 Thread 'Axel Wagner' via golang-nuts 
On Wed, Jul 1, 2020 at 1:10 AM roger peppe  wrote:

> LGTM. This is a welcome change. I often need to look up how to spell
> "// +build" currently :)
>
> One thing I'd really like to see is the eventual deprecation of
> filename-based build constraints (e.g. file_linux.go).
> They make it hard for users (not everyone knows the name of all
> architectures), hard for tooling (tools
> need to maintain a list of current architectures) and potentially
> compatibility-breaking (adding
> a new architecture can change the meaning of existing files). Could we
> eventually mandate
> in-file build constraints instead?
>

I think *mandating* this could be considered a backwards incompatible
change (the only real counter-argument is that it's "just tooling"). AIUI,
Russ' design doesn't actually remove `// +build` for this reason, but only
deprecates it with automatic re-writing.
Of course, nothing would prevent us from doing the same - deprecating
purely filename-based constraints and have `gofmt` actively add build tags.
Note that the filenames wouldn't go away anyways; you still need separate
files, so you still need separate names. You wouldn't need *these specific*
names, but you'd probably end up with very similar ones.

If you'd indeed suggest removing file name based constraints altogether,
I'd argue that it should probably happen in this same process (not
"eventually" :) ) - it involves touching ~every Go package with constraints
anyway, so having to only do this once would probably be preferable.


>
>   cheers,
> rog.
>
>
> On Tue, 30 Jun 2020 at 21:04, Russ Cox  wrote:
>
>> Hi all,
>>
>> I've posted a draft design for replacing // +build lines with //go:build
>> lines that support standard boolean expression syntax. It is a draft design
>> I'm circulating for feedback, not an official proposal. (I certainly hope
>> it will be well received and can be made into a proposal, but that's not
>> where we are today.)
>>
>> If you are interested, there is a doc and a video, linked below. As an
>> experiment, I'd like to try using Reddit for the discussion, also linked
>> below. The idea is that proper threading support should scale better than
>> GitHub or a single large mail thread here would. But for those who don't do
>> Reddit, I will keep an eye on this thread and reply as best I can.
>>
>> Video: https://golang.org/s/go-build-video
>> Design: https://golang.org/s/go-build-design
>> Q: https://golang.org/s/go-build-reddit
>>
>> Thanks!
>>
>> Best,
>> Russ
>>
>> --
>> 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/CAA8EjDTO1NX%3DacOTqEfD%3D6pumUWzNNcGO%2BsPMrQVYdO0cmWsvQ%40mail.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/CAJhgacjXjt%2BhKVOLadcRxvwMnWRMJS%2BPwnKt8GdCa%2Bc77GUmRQ%40mail.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/CAEkBMfE5_nmDLd_WNO88ChzSoVAh77mCxgxEreo9xa%2BuN77fkQ%40mail.gmail.com.

Re: [go-nuts] draft design for // +build replacement

2020-06-30 Thread roger peppe 
LGTM. This is a welcome change. I often need to look up how to spell
"// +build" currently :)

One thing I'd really like to see is the eventual deprecation of
filename-based build constraints (e.g. file_linux.go).
They make it hard for users (not everyone knows the name of all
architectures), hard for tooling (tools
need to maintain a list of current architectures) and potentially
compatibility-breaking (adding
a new architecture can change the meaning of existing files). Could we
eventually mandate
in-file build constraints instead?

  cheers,
rog.


On Tue, 30 Jun 2020 at 21:04, Russ Cox  wrote:

> Hi all,
>
> I've posted a draft design for replacing // +build lines with //go:build
> lines that support standard boolean expression syntax. It is a draft design
> I'm circulating for feedback, not an official proposal. (I certainly hope
> it will be well received and can be made into a proposal, but that's not
> where we are today.)
>
> If you are interested, there is a doc and a video, linked below. As an
> experiment, I'd like to try using Reddit for the discussion, also linked
> below. The idea is that proper threading support should scale better than
> GitHub or a single large mail thread here would. But for those who don't do
> Reddit, I will keep an eye on this thread and reply as best I can.
>
> Video: https://golang.org/s/go-build-video
> Design: https://golang.org/s/go-build-design
> Q: https://golang.org/s/go-build-reddit
>
> Thanks!
>
> Best,
> Russ
>
> --
> 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/CAA8EjDTO1NX%3DacOTqEfD%3D6pumUWzNNcGO%2BsPMrQVYdO0cmWsvQ%40mail.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/CAJhgacjXjt%2BhKVOLadcRxvwMnWRMJS%2BPwnKt8GdCa%2Bc77GUmRQ%40mail.gmail.com.

[go-nuts] draft design for // +build replacement

2020-06-30 Thread Russ Cox 
Hi all,

I've posted a draft design for replacing // +build lines with //go:build
lines that support standard boolean expression syntax. It is a draft design
I'm circulating for feedback, not an official proposal. (I certainly hope
it will be well received and can be made into a proposal, but that's not
where we are today.)

If you are interested, there is a doc and a video, linked below. As an
experiment, I'd like to try using Reddit for the discussion, also linked
below. The idea is that proper threading support should scale better than
GitHub or a single large mail thread here would. But for those who don't do
Reddit, I will keep an eye on this thread and reply as best I can.

Video: https://golang.org/s/go-build-video
Design: https://golang.org/s/go-build-design
Q: https://golang.org/s/go-build-reddit

Thanks!

Best,
Russ

-- 
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/CAA8EjDTO1NX%3DacOTqEfD%3D6pumUWzNNcGO%2BsPMrQVYdO0cmWsvQ%40mail.gmail.com.

Re: [go-nuts] [generics] Syntax feedback

2020-06-30 Thread Tyler Compton 
Hi Andrey,

Unfortunately, I don't believe I can edit mailing list posts even on the
Google Groups page. Sorry to have missed your post originally!

On Sun, Jun 28, 2020 at 1:09 PM Andrey T. 
wrote:

> Tyler,
> May I humbly suggest
> https://groups.google.com/d/msg/golang-nuts/W3fSnH0w1G0/JbMkJrKICAAJ for
> an additional item for your list?
>
> Thank you very much,
>   Andrey
>
> On Saturday, June 27, 2020 at 11:46:23 AM UTC-6, Tyler Compton wrote:
>>
>> Hi Rob,
>>
>> This topic has been discussed many times on this list, so it's probably
>> best to look at and post in one of those threads. Let me take this chance
>> to collect as much information about this issue as I can in a single post.
>> Unfortunately, discoverability can sometimes be hard on mailing lists so
>> I don't blame you for not seeing all these.
>>
>> Responses on the subject:
>> Design draft talking about alternative syntax:
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java
>> Ian's justification for taking a wait-and-see approach to this syntax
>> issue: https://groups.google.com/g/golang-nuts/c/Rumm5HFhg_Q
>>
>> Threads:
>> Use "<>": https://groups.google.com/g/golang-nuts/c/LvkOBA2D_Bk
>> Use "<>": https://groups.google.com/g/golang-nuts/c/B1Q1dsLa5rk
>> Use "::" and other suggestions:
>> https://groups.google.com/g/golang-nuts/c/b0GydCIn7T0
>> Use "(<>)": https://groups.google.com/g/golang-nuts/c/tYwWeiMztiI
>> Use "<>" before the name of the type being defined:
>> https://groups.google.com/g/golang-nuts/c/TJWGbrx2o34
>> Put type parameters in the regular arguments list with a ":type" suffix:
>> https://groups.google.com/g/golang-nuts/c/K7s-5MeXuzM
>> Use "<>", with some kind of additional syntax to make parsing easier:
>> https://groups.google.com/g/golang-nuts/c/SaDkSQdgF9g
>> Use "<>": https://groups.google.com/g/golang-nuts/c/coi7YS0KPgQ
>> Use "<>": https://groups.google.com/g/golang-nuts/c/ydySSqZqi-0
>> Use ":[]": https://groups.google.com/g/golang-nuts/c/zGQq_I5r2jg
>> No specific suggestion:
>> https://groups.google.com/g/golang-nuts/c/mY_36VU5ij8
>>
>> --
> 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/32da9686-d144-4d35-924f-b2bb1de7d9b3o%40googlegroups.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/CAA%3DXfu2-F-TCVQs%2Boskgz54pN6noXTkdtnzZt3r7Aezwe-oBOw%40mail.gmail.com.

[go-nuts] Help? Looking for info on how net/http and net/http2 are supposed to interact in the context of noDialClientConnPool

2020-06-30 Thread Chris Friesen 
Hi all,

I've got a weird bug in Kubernetes where an unclean shutdown of 
kube-apiserver sometimes causes kubelet to lose connectivity with 
kube-apiserver and then get stuck in a mode where it's unable to regain 
connectivity.  Looking at the running "stuck" kubelet process with strace I 
see it opening up a connection to kube-apiserver, sending and receiving 
some data, then close()ing the socket.  It's only open for about 5ms or 
so.  In the typical case the connection stays open indefinitely so I'm not 
sure what's causing it to get closed.

After attaching delve to the stuck process, it looks like 
net/http/transport.go is calling into net/http2/transport.go, but that 
returns an error of ErrNoCachedConn because we're 
using noDialClientConnPool and there are no cached connections.

I'm still trying to figure out how this is *supposed* to work, so that I 
can figure out what's going wrong.  The code comment says, "We let the 
HTTP/1.1 client dial and use its TLS connection instead."

Anyone have any pointers?  Is there any documentation on this?

Thanks,
Chris

-- 
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/de632279-bd99-4446-b719-38dbc2e189dfo%40googlegroups.com.

[go-nuts] run golang cpu profile for 5mins but only got 1.64mins (32.69%) samples

2020-06-30 Thread lqiyangl 


$ go version
go version go1.13.10

In the container, the golang process used 100% of the CPU. When I took a 
5minutes CPU profile, the result shows that only 1.64mins (32.69%) samples 
are returned. Is it normal?

go tool pprof autoscaler_cpuprofile.out
File: autoscaler
Type: cpu
Time: Jun 29, 2020 at 11:21pm (CST)
Duration: 5.01mins, Total samples = 1.64mins (32.69%)

-- 
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/2e0eafdf-e901-447a-82a2-70ce18e0dedao%40googlegroups.com.

[go-nuts] Re: Building multiple executables from one module

2020-06-30 Thread Brian Candler 
Thank you!

go build -o . ./...

does the trick.  And now I know what I'm looking for, I can find it in the 
documentation:

*When compiling multiple packages or a single non-main package, build 
compiles the packages but discards the resulting object, serving only as a 
check that the packages can be built.*


*The -o flag forces build to write the resulting executable or object to 
the named output file or directory, instead of the default behavior 
described in the last two paragraphs.*


Thanks again,

Brian.

-- 
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/4450d4b4-9770-42b9-89c1-a87a9f423293o%40googlegroups.com.

[go-nuts] Re: Building multiple executables from one module

2020-06-30 Thread seank...@gmail.com 
go build -o output_directory ./...

On Tuesday, June 30, 2020 at 12:58:05 PM UTC+2 b.ca...@pobox.com wrote:

> Suppose I have a tree of files like this, to build two executables:
>
> ==> ./go.mod <==
> module example.com/test
>
> go 1.14
>
> ==> ./shared.go <==
> package example
>
> const Answer = 42
>
> ==> ./bin/test1/main1.go <==
> package main
>
> import (
> . "example.com/test"
> "fmt"
> )
>
> func main() {
> fmt.Printf("%s, answer is %d\n", Message, Answer)
> }
>
> ==> ./bin/test1/dep1.go <==
> package main
>
> const Message = "hello"
>
> ==> ./bin/test2/main2.go <==
> package main
>
> import (
> . "example.com/test"
> "fmt"
> )
>
> func main() {
> fmt.Printf("%s, answer was %d\n", Message, Answer)
> }
>
> ==> ./bin/test2/dep2.go <==
> package main
>
> const Message = "goodbye"
>
> Ideally I'd like a way to build the executables in a single command.  
> Currently I enter each directory and build explicitly, i.e.
>
> for d in bin/*; do (cd $d && go build); done
>
> If at the top level I do "go build ./...", the executables don't get 
> built.  Something happens, because it takes a fraction of a second to 
> return, but nothing is written out as far as I can see.
>
> The documentation  says:
>
> -buildmode=default
>   Listed main packages are built into executables and listed
>   non-main packages are built into .a files (the default
>   behavior).
>
>
> This implies multiple "main packages" can be built into multiple 
> "executables" in one command.
>
> But how is a main package "listed"?  I tried:
>
> $ go build bin/test1
> can't load package: package bin/test1 is not in GOROOT 
> (/usr/local/go/src/bin/test1)
> $ go build bin/test1/main
> can't load package: package bin/test1/main is not in GOROOT 
> (/usr/local/go/src/bin/test1/main)
> $ go build bin/test1/...
> go: warning: "bin/test1/..." matched no packages
> go: warning: "bin/test1/..." matched no packages
> $ go build bin/test1/main1.go
> # command-line-arguments
> bin/test1/main1.go:9:35: undefined: Message
>
> The following is accepted, but as far as I can see does not create any 
> files:
>
> $ go build example.com/test/bin/test1 example.com/test/bin/test2
> $ 
>
> Just like "go build ./...", it takes a noticeable fraction of a second, 
> but nothing is written out.  I've look in the top level, inside the 
> bin/test[12] directories, and  "find ~/go -mtime -1"
>
> If I build one at a time, it works, yay!
>
> $ go build example.com/test/bin/test1
> $ go build example.com/test/bin/test2
> $ ls
> bin  go.mod  shared.go test1  test2
>
> ... but the documentation says I ought to be able to list multiple main 
> packages, so I'm clearly missing something.
>
> It seems when I build a single package, it gets moved to the final 
> location:
>
> $ go build -x example.com/test/bin/test1
> ...
> /usr/local/go/pkg/tool/linux_amd64/buildid -w $WORK/b001/exe/a.out # 
> internal
> mv $WORK/b001/exe/a.out test1
> rm -r $WORK/b001/
> $ 
>
> but not when I build two:
>
> $ go build -x example.com/test/bin/test1 example.com/test/bin/test2
> ...
> /usr/local/go/pkg/tool/linux_amd64/buildid -w $WORK/b033/exe/a.out # 
> internal
> /usr/local/go/pkg/tool/linux_amd64/buildid -w $WORK/b001/exe/a.out # 
> internal
> $ 
>
> That's as far as I've got.  (Incidentally, I see the same with "go build 
> -x ./...")
>
> Any clues?
>
> Thanks,
>
> Brian.
>
> P.S.
> $ go version
> go version go1.14.4 linux/amd64
>
>

-- 
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/e0ca3474-2f02-4e8d-bc36-b5af043b7139n%40googlegroups.com.

[go-nuts] Building multiple executables from one module

2020-06-30 Thread Brian Candler 
Suppose I have a tree of files like this, to build two executables:

==> ./go.mod <==
module example.com/test

go 1.14

==> ./shared.go <==
package example

const Answer = 42

==> ./bin/test1/main1.go <==
package main

import (
. "example.com/test"
"fmt"
)

func main() {
fmt.Printf("%s, answer is %d\n", Message, Answer)
}

==> ./bin/test1/dep1.go <==
package main

const Message = "hello"

==> ./bin/test2/main2.go <==
package main

import (
. "example.com/test"
"fmt"
)

func main() {
fmt.Printf("%s, answer was %d\n", Message, Answer)
}

==> ./bin/test2/dep2.go <==
package main

const Message = "goodbye"

Ideally I'd like a way to build the executables in a single command.  
Currently I enter each directory and build explicitly, i.e.

for d in bin/*; do (cd $d && go build); done

If at the top level I do "go build ./...", the executables don't get 
built.  Something happens, because it takes a fraction of a second to 
return, but nothing is written out as far as I can see.

The documentation  says:

-buildmode=default
Listed main packages are built into executables and listed
non-main packages are built into .a files (the default
behavior).


This implies multiple "main packages" can be built into multiple 
"executables" in one command.

But how is a main package "listed"?  I tried:

$ go build bin/test1
can't load package: package bin/test1 is not in GOROOT 
(/usr/local/go/src/bin/test1)
$ go build bin/test1/main
can't load package: package bin/test1/main is not in GOROOT 
(/usr/local/go/src/bin/test1/main)
$ go build bin/test1/...
go: warning: "bin/test1/..." matched no packages
go: warning: "bin/test1/..." matched no packages
$ go build bin/test1/main1.go
# command-line-arguments
bin/test1/main1.go:9:35: undefined: Message

The following is accepted, but as far as I can see does not create any 
files:

$ go build example.com/test/bin/test1 example.com/test/bin/test2
$ 

Just like "go build ./...", it takes a noticeable fraction of a second, but 
nothing is written out.  I've look in the top level, inside the 
bin/test[12] directories, and  "find ~/go -mtime -1"

If I build one at a time, it works, yay!

$ go build example.com/test/bin/test1
$ go build example.com/test/bin/test2
$ ls
bin  go.mod  shared.go test1  test2

... but the documentation says I ought to be able to list multiple main 
packages, so I'm clearly missing something.

It seems when I build a single package, it gets moved to the final location:

$ go build -x example.com/test/bin/test1
...
/usr/local/go/pkg/tool/linux_amd64/buildid -w $WORK/b001/exe/a.out # 
internal
mv $WORK/b001/exe/a.out test1
rm -r $WORK/b001/
$ 

but not when I build two:

$ go build -x example.com/test/bin/test1 example.com/test/bin/test2
...
/usr/local/go/pkg/tool/linux_amd64/buildid -w $WORK/b033/exe/a.out # 
internal
/usr/local/go/pkg/tool/linux_amd64/buildid -w $WORK/b001/exe/a.out # 
internal
$ 

That's as far as I've got.  (Incidentally, I see the same with "go build -x 
./...")

Any clues?

Thanks,

Brian.

P.S.
$ go version
go version go1.14.4 linux/amd64

-- 
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/8c0078e6-12a0-48e3-aa78-05dbaaa3339fo%40googlegroups.com.

Re: [go-nuts] Goroutines count and id

2020-06-30 Thread Hugo Cornelis 
If you want to identify goroutines at runtime, you can find in the
attachments patches for Golang 1.10 to allow to assign a name to a
goroutine.

These are patches against Golang 1.10 because I have been using the gccgo
runtime that comes with GCC 8.4.

This could help you forward for what you want.

Hugo


On Tue, Jun 30, 2020 at 9:50 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Tue, Jun 30, 2020 at 9:36 AM Durga Someswararao G
>  wrote:
>
> > Is it possible to get goroutine id when we creted?
> > Is it possible to get goroutines count while we creating?
> > Is it possible to terminate a goroutine based on ID like if any
> goroutine has infinite loops?
> > Is it possible to clean up memory of variable like we have free in C?
>
> The answer to all of the above questions, in the first approximation, is
> no.
>
> Unsafe tricks may help to achieve some of those goals. What's the
> purpose? Is this a XY problem?
>
> --
> 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-ULnCkc7hw0c%3DQCTSAvyP3ZO4rXmTEjm5fb6m2QTJC%3Duw%40mail.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/CAARrXCTo3W4s6ahPDNHktU6U_uefRbjnENiDNkfA6Smqb7BCqg%40mail.gmail.com.
From 99d77ef6698838e3c77178a2c719369b3cac9f25 Mon Sep 17 00:00:00 2001
From: Hugo Cornelis 
Date: Tue, 2 Jun 2020 19:44:08 +0200
Subject: [PATCH 2/2] improved goroutine name reporting wrt parsing

---
 libgo/go/runtime/traceback_gccgo.go | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libgo/go/runtime/traceback_gccgo.go b/libgo/go/runtime/traceback_gccgo.go
index b53dc6f8e30..652d3d7ba71 100644
--- a/libgo/go/runtime/traceback_gccgo.go
+++ b/libgo/go/runtime/traceback_gccgo.go
@@ -8,6 +8,7 @@
 package runtime
 
 import (
+	"os"
 	"runtime/internal/sys"
 	"sync/atomic"
 	"unsafe"
@@ -15,6 +16,9 @@ import (
 
 func GoroutineSetName(name string) {
 	var length uint32
+
+	os.Stderr.WriteString("GoroutineSetName(" + name + ")\n")
+
 	if len(name) > GoroutineNameLengthMax {
 		length = GoroutineNameLengthMax
 	} else {
@@ -28,6 +32,7 @@ func GoroutineSetName(name string) {
 	atomic.StoreUint32(&_g_.nameLength, 0)
 	copy(_g_.name[:], name[0:length])
 	atomic.StoreUint32(&_g_.nameLength, length)
+
 }
 
 func printcreatedby(gp *g) {
@@ -174,7 +179,7 @@ func goroutineheader(gp *g) {
 	nameLength := atomic.LoadUint32()
 
 	if nameLength != 0 {
-		print("goroutine ", gp.goid, " '")
+		print("goroutine, name: ", gp.goid, " '")
 		gwrite(gp.name[0:nameLength])
 		print("' [", status)
 	} else {
-- 
2.17.1

From 89996ebc2d19c9a8e0ee7d567c95430d81f42b26 Mon Sep 17 00:00:00 2001
From: Hugo Cornelis 
Date: Mon, 18 May 2020 14:49:03 +0200
Subject: [PATCH 1/2] added goroutine naming

---
 libgo/go/runtime/proc.go|  1 +
 libgo/go/runtime/runtime2.go|  7 +++
 libgo/go/runtime/traceback_gccgo.go | 32 -
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/libgo/go/runtime/proc.go b/libgo/go/runtime/proc.go
index a6746c9f0a8..10a2ffc2f62 100644
--- a/libgo/go/runtime/proc.go
+++ b/libgo/go/runtime/proc.go
@@ -2614,6 +2614,7 @@ func goexit0(gp *g) {
 	gp.param = nil
 	gp.labels = nil
 	gp.timer = nil
+	gp.nameLength = 0
 
 	if gcBlackenEnabled != 0 && gp.gcAssistBytes > 0 {
 		// Flush assist credit to the global pool. This gives
diff --git a/libgo/go/runtime/runtime2.go b/libgo/go/runtime/runtime2.go
index 0299d5a788f..0ff04fa867a 100644
--- a/libgo/go/runtime/runtime2.go
+++ b/libgo/go/runtime/runtime2.go
@@ -88,6 +88,10 @@ const (
 	_Gscanwaiting  = _Gscan + _Gwaiting  // 0x1004
 )
 
+const (
+	GoroutineNameLengthMax = 30
+)
+
 const (
 	// P status
 	_Pidle= iota
@@ -435,6 +439,9 @@ type g struct {
 
 	context  g_ucontext_t // saved context for setcontext
 	stackcontext [10]uintptr  // split-stack context
+
+	nameLength uint32
+	name[GoroutineNameLengthMax] uint8
 }
 
 type m struct {
diff --git a/libgo/go/runtime/traceback_gccgo.go b/libgo/go/runtime/traceback_gccgo.go
index 8551ec19ac3..b53dc6f8e30 100644
--- a/libgo/go/runtime/traceback_gccgo.go
+++ b/libgo/go/runtime/traceback_gccgo.go
@@ -9,9 +9,27 @@ package runtime
 
 import (
 	"runtime/internal/sys"
+	"sync/atomic"
 	"unsafe"
 )
 
+func GoroutineSetName(name string) {
+	var length uint32
+	if len(name) > GoroutineNameLengthMax {
+		length = GoroutineNameLengthMax
+	} else {
+		length = uint32(len(name))
+	}
+
+	_g_ := getg()
+
+	//! is locking required here?  Play safe wrt goroutineheader().
+

Re: [go-nuts] Does golang uses copyOnWrite like java? where?

2020-06-30 Thread fgergo 
Google copy on write go and you'll see the details. (The anwser is no.)
Also you might be interested in these:
https://golang.org/doc/faq#pass_by_value
https://golang.org/doc/faq#go_or_golang

(The faq is quite informative.)

cheers

On Tue, Jun 30, 2020, 06:15 刘骏龙  wrote:

> THX
>
> --
> 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/ba52a326-502e-4320-8573-efc7409ce773n%40googlegroups.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/CA%2BctqrpNVGnMz8Q6P4Q-pwmMfi0m6Q%2Bv8psGpExP3Ae%3DpjDJxA%40mail.gmail.com.

Re: [go-nuts] Goroutines count and id

2020-06-30 Thread Jan Mercl 
On Tue, Jun 30, 2020 at 9:36 AM Durga Someswararao G
 wrote:

> Is it possible to get goroutine id when we creted?
> Is it possible to get goroutines count while we creating?
> Is it possible to terminate a goroutine based on ID like if any goroutine has 
> infinite loops?
> Is it possible to clean up memory of variable like we have free in C?

The answer to all of the above questions, in the first approximation, is no.

Unsafe tricks may help to achieve some of those goals. What's the
purpose? Is this a XY problem?

-- 
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-ULnCkc7hw0c%3DQCTSAvyP3ZO4rXmTEjm5fb6m2QTJC%3Duw%40mail.gmail.com.

[go-nuts] Goroutines count and id

2020-06-30 Thread Durga Someswararao G 
Hi,
Can some one help for below queries

Is it possible to get goroutine id when we creted?
Is it possible to get goroutines count while we creating?
Is it possible to terminate a goroutine based on ID like if any goroutine 
has infinite loops?
Is it possible to clean up memory of variable like we have free in C?

Thanks,
Durga SomeswaraRao G.

-- 
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/a4b9ed05-506c-405d-8f6f-2a30a480333do%40googlegroups.com.

[go-nuts] Re: can a sub-directory package of a module be imported?

2020-06-30 Thread Volker Dobler 

On Tuesday, 30 June 2020 06:34:48 UTC+2, Jason E. Aten wrote:
>
> I have a files laid out like this (OSX):
>
> ~/go/src/github.com/user/fish/api/client/wanda.go
>
> ~/go/src/github.com/user/fish/go.mod with first line "module 
> github.com/liked/movies/v2"
>
> ~/go/src/github.com/user/fish/cmd/demo/main.go that does: import client "
> github.com/liked/movies/v2/api/client"
>
> ~/go/src/github.com/user/fish/cmd/demo $ go build  ## with GO111MODULE 
> unset, under go1.14.4. Also GOPRIVATE=github.com/user   and 
> GOPATH=$HOME/go
>  
> go: finding module for package github.com/liked/movies/v2/api/client
> main.go:4:2: module github.com/liked/movies/v2@latest found 
> (v2.0.0-alpha.1), but does not contain package 
> github.com/liked/movies/v2/api/client
>
> So the demo/main.go import of the client package is not resolved. Is it 
> possible, in general, to import a package within a module? 
>

Yes, of course.

Start of by deciding whether you want to use Go Modules or
GOPATH builds and set GO111MODULE accordingly. Your
setup uses the defaults which change from release to release
and doing it in a deterministic way.

Then: You did not show the package clause of wanda.go.

It is strange that cmd/demo doesn't recognize its own module.
Is there a fundamental reason to name the module github.com/liked/movies
while the repo is github.com/user/fish ?

Last: Did you try a replace directive?

V.
 
 

-- 
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/8c21dc52-9aa9-4d36-9029-ede4f93d7702o%40googlegroups.com.