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
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)
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
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
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
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
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
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
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
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
>
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
$ 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,
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
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 =
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
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
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
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
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
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"
>
>
20 matches
Mail list logo