profile
viewpoint

issue closedgolang/go

x/pkgsite:

<placeholder>

closed time in a day

julieqiu

issue closedgolang/go

x/pkgsite:

<placeholder>

closed time in a day

julieqiu

issue closedgolang/go

x/pkgsite:

<placeholder>

closed time in a day

julieqiu

issue closedgolang/go

x/pkgsite:

<placeholder>

closed time in a day

julieqiu

issue commentgolang/go

proposal: Go 2: builtin add func resize(v Type, size)

"I prefer passing the additional capacity" So when discussing further should it be assumed the proposal means the hint is to be used for additional capacity?

Can you elaborate what that means for the current hash map implementation. e.g. is the hint making sure there is at least that much open slots somewhere in the map buckets including overflow buckets? Note that depending on hash collisions that does not mean adding that much elements doesnt cause a map growth to happen.

elichai

comment created time in a day

issue commentgolang/go

proposal: Go 2: builtin add func resize(v Type, size)

A few questions as the semantics of resize havent been spelled out completly yet:

Assuming: "2: (hint the max cap we want)"

What happens when the hinted at capacity is smaller than the existing capacity: Does the builtin downsize the map?

Does the resize happen for the whole map immediatly or is it done by having each write and delete do a bit of the resize like current map growth?

What happens if the hint provided is larger than a map is allowed to be (exceeding memory limits)?

elichai

comment created time in a day

issue commentgolang/go

proposal: Go 2: builtin add func resize(v Type, size)

The map examples given just show adding elements. There would need to be an additional resize call that is trying to more then double the capacity. If its not more than doubling the internal resize mechanism of maps would do the same as the resize on the fly already. A resize will need to also copy all elements to a new map allocation in the current design of maps to grow the map. Spending alot of time in mapassign is not necessarily a sign of map growth but can entirely be generated by just adding elements to a big enough map.

More details can be added in an extra comment or in the top comment.

elichai

comment created time in 2 days

issue commentgolang/go

proposal: add per-goroutine CPU stats

A possible solution to showing high level usage of different query paths can be achieved by setting profiling labels on the goroutine: https://golang.org/src/runtime/pprof/runtime.go?s=1362:1432#L26

And doing background profiling on the job: https://go-review.googlesource.com/c/go/+/102755

asubiotto

comment created time in 2 days

issue closedgolang/go

runtime: interface hash table not Quadratic Probing

i read soource code about interface hash table. the code say hash use Quadratic Probing. but absolutely not. this is just h +=i not h +=i *i, this is a special design or a bug?


func (t *itabTableType) find(inter *interfacetype, typ *_type) *itab {
	// Implemented using quadratic probing.
	// Probe sequence is h(i) = h0 + i*(i+1)/2 mod 2^k.
	// We're guaranteed to hit all table entries using this probe sequence.
	mask := t.size - 1
	h := itabHashFunc(inter, typ) & mask
	for i := uintptr(1); ; i++ {
		p := (**itab)(add(unsafe.Pointer(&t.entries), h*sys.PtrSize))
		// Use atomic read here so if we see m != nil, we also see
		// the initializations of the fields of m.
		// m := *p
		m := (*itab)(atomic.Loadp(unsafe.Pointer(p)))
		if m == nil {
			return nil
		}
		if m.inter == inter && m._type == typ {
			return m
		}
		h += i
		h &= mask
	}
}

closed time in 2 days

dreamerjackson

issue commentgolang/go

runtime: interface hash table not Quadratic Probing

h is increased by and i that is increasing on every iteration. If it would be linear the addition would be by a costant e.g. h += 10.

dreamerjackson

comment created time in 2 days

issue commentgolang/go

proposal: Go 2: builtin add func resize(v Type, size)

Heh, @martisch, your instructions to tell the bot to remove the label just removed the label. I don't think it knows how to tell that your comment came before the label was added.

Ack. ordering error on my part ...

elichai

comment created time in 2 days

issue commentgolang/go

proposal: Go 2: builtin add func resize(v Type, size)

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.

Thanks!

elichai

comment created time in 2 days

issue commentgolang/go

proposal: builtin add func resize(v Type, size)

"With slices you could make a new slice, copy over and assign to the current slice, but with maps/channels it is harder." Is it really that much harder for maps?

new := make(map[X]Y, capacity) for key, value := range old { new[key] = value } If performance is a concern that can solved without a language change: https://github.com/golang/go/issues/26951

elichai

comment created time in 2 days

issue commentgolang/go

memory corruption on linux/386 with float32 arithmetic, GO386=387, buildmode pie/c-archive

/cc @cherrymui @thanm @randall77

BenLubar

comment created time in 3 days

issue commentgolang/go

proposal: Go 2: OR operator on error return

See https://github.com/golang/go/issues/40432 for past error handling proposals and associated design problems.

Codebreaker101

comment created time in 3 days

issue commentgolang/go

proposal: Go 2: OR operator on error return

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.

Thanks!

Codebreaker101

comment created time in 3 days

issue commentgolang/go

proposal: testing: add CPU name to standard benchmark labels

I tested a bit around and AT_PLATFORM is mostly not useful as it will only print along the lines of x86_64, aarch64 and similar.

Parsing /proc/cpuinfo will cover all Linux based combinations but unfortunately is more complex than a first glance might suggest. Every architecture on Linux has its own format to store the specify CPU name in differently named fields.

On *BSDs it seems we can get information using sysctl calls that are already implemented in the runtime. I have however not tested how differ across architectures and some *BSDs we may need to implement a sysctlbyname call first if the MIBs are not static.

So in a first iteration it seems we could cover all of x86, amd64 and Linux leaving these not supported initially: aix/ppc64 darwin/arm64 freebsd/arm freebsd/arm64 js/wasm netbsd/arm netbsd/arm64 openbsd/arm openbsd/arm64 plan9/arm windows/arm

martisch

comment created time in 3 days

issue commentgolang/go

memory corruption on android/386 with float32 arithmetic

Does the computer you build on support SSE2? Otherwise 387 is set. https://github.com/golang/go/blob/24ff2af65e27eed1e8c7f09c21a5ca68fc2e07ab/src/cmd/dist/build.go#L146

Can the problem be reproduced on linux/386 with GO386=387?

BenLubar

comment created time in 3 days

issue commentgolang/go

proposal: testing: add CPU name to standard benchmark labels

@ceseo both are already used on ppc64x: https://github.com/golang/go/blob/8174f7fb2b64c221f7f80c9f7fd4d7eb317ac8bb/src/runtime/os_linux_ppc64x.go#L14 https://github.com/golang/go/blob/8174f7fb2b64c221f7f80c9f7fd4d7eb317ac8bb/src/internal/cpu/cpu_ppc64x.go#L39

martisch

comment created time in 8 days

issue commentgolang/go

proposal: testing: add CPU name to standard benchmark labels

@ceseo thanks for pointing this out. I will try to ammend my patch for Linux on all platforms to get AT_PLATFORM from the aux vector. We already use the same mechanism to get HWCAP bits from AT_HWCAP in the auxillary vector.

martisch

comment created time in 8 days

issue commentgolang/go

proposal: testing: add CPU name to standard benchmark labels

On all operating systems for 386 and amd64 we can use the CPUID instruction (see http://golang.org/cl/234977) to get the CPU name.

Generally for linux on other architectures /proc/cpuinfo can be used.

For ARM on all operating systems another (more indirect) but not as universal approach can be to read the model and vendor with CPU instructions and then map those to common architecture names for the most common CPUs (e.g. Cortex-A55, Cortex-A77 ...).

martisch

comment created time in 8 days

issue openedgolang/go

access: restore try/slow-bot and abandon rights for martisch

With the trust rule changes and account cleanups in https://github.com/golang/go/issues/40699 all rights have been stripped from some accounts.

Please restore rights to run try/slow bots and abandon changes on gerrit for account https://go-review.googlesource.com/q/owner:martisch%2540uos.de

/cc @golang/osp-team

created time in 10 days

issue commentgolang/go

runtime: add GODEBUG=traceinit=1 support

In principle possible with the following caveats that come into my mind:

  • to be able to profile all std lib packages one would need to find the first init function and start the profiling in there or add a GODEBUG flag to immediately start profiling (the user wanting to trace might not have the ability to change the std library)
  • interrupt driven profiling is sample based and especially for small init functions will require a lot of samples to approximate all init runtimes. we can instead measure with init tracing the same values we are trying to sample with profiling.
  • profiling flame graphs or summaries usually do not have any ordering (init foo happend before init bar)
martisch

comment created time in 10 days

issue openedgolang/go

runtime: add GODEBUG=traceinit=1 support

Note: Like #38714 this is not a proposal for the proposal process.

This issue is to discuss and track the addition of support for init function tracing through GODEBUG for ad hoc debugging and profiling of init start times.

Prototype CL: https://go-review.googlesource.com/c/go/+/254659

For the first minimal implementation (future iterations can expand functionality) I think that just showing the package name, start time of the init function, wall clock duration and total heap allocated bytes and number of allocs is sufficient. Later information like module version could be added.

Due to much larger complexity init tracing of plugins is not supported.

Having a more structured format like json output is omitted and likely needs a more holistic approach and decision in unison with adding support for gctrace in json format too.

/cc @mknyszek @aclements @randall77 @prattmic

created time in 10 days

issue commentgolang/go

proposal: Go 2: add native type for map that maintains key order

the generics approach would also not be picked up by stdlib as changing the map implementation would

Could you explain why not? I dont think the std lib is prohibited from using generics once the compiler supports them. Changing the stdlib API if a type is exposed would need to be done with generics and with a new map type and both times break backward compatibility.

andig

comment created time in 14 days

issue commentgolang/go

runtime: append growth sort of inconsistent and surprising

If we are going to change it I think go1.16 is a good time as adding a 24byte size class is about to change append capacity allocated already. Batching up these changes up will also batch up some Go code needing to be corrected to not assume capacities grown into by append are consistent between Go versions and we can communicate the changes and potential differences seen between Go versions for multiple CLs together.

seebs

comment created time in 14 days

issue commentgolang/go

cmd/asm: VMOVQ misassembled to VMOVD on 386

Does VMOVQ (SI), AX exist?

c5fa7e06 is vmovq xmm0,QWORD PTR [esi] and https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-2b-manual.pdf seems to suggest it only works with xmm registers.

fuzxxl

comment created time in 15 days

issue commentgolang/go

proposal: Go2: add native type for map that maintains key order

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.

Thanks!

andig

comment created time in 15 days

issue closedgolang/go

Help

closed time in 16 days

kbshadow87
GollumEvent

issue commentgolang/go

runtime: append growth sort of inconsistent and surprising

EDIT: just tried []int on play.golang.org and found it rounds up cap to an even number, so wastes 1 half the time.

Im not sure why the additional fields for the cap are considered wasted. Those bytes would be unusable otherwise as the Go gc allocator doesnt e.g. support just reserving three 64bit ints. The next size class that can be allocated are four 64 bit ints. So if append would cut that down to three three 64bit ints it would actually wasted one 64bit int that nothing can ever use until the slice is garbage collected. But making it four 64bit ints that one int can actually be used if one more element is appended. The context needed to understand the append behaviour is that the current Go gc allocator does not support allocating arbitrary sizes of memory for small sizes: https://github.com/golang/go/blob/master/src/runtime/sizeclasses.go

seebs

comment created time in 18 days

issue commentgolang/go

runtime: append growth sort of inconsistent and surprising

I do not think appends focus should be to be a slice clone mechanism. I do not agree with the idea that because currently its possible to write a slice clone with append in one line and it isn't perfect append needs to change to make it perfect in one line. If a "perfect" slice clone mechanism is needed lets explore how often the nil-ness of slice matters for the copy. I have not seen it come very often and make+copy seems concise enough to me.

seebs

comment created time in 18 days

issue commentgolang/go

runtime: append growth sort of inconsistent and surprising

If nil vs non-nil is important:

var b []T
if a != nil {
	b = make([]T, len(a))
	copy(b, a)
}

Which nicely conveys explicitly that the case of a == nil is special. For append(src[:0:0], src..) that nil might be special is easily lost as its implicit.

For the more common case I have seen where only length matters (its often an API problem if nil for a slices is handled differently then len(slice) == 0) these to lines are nicely explicit in the meaning and optimised better than append:

b := make([]T, len(a))
copy(b, a)
seebs

comment created time in 18 days

issue commentgolang/go

runtime: append growth sort of inconsistent and surprising

If a perfect clone is wanted a make with an explicit cap and copy seems the right fit. Using append for that starting from a 0 cap slice seems like a hack to avoid writing more than a one liner.

seebs

comment created time in 18 days

issue commentgolang/go

runtime: append growth sort of inconsistent and surprising

I agree with @ianlancetaylor that the slice capacities that append produces should not be relied on to be consistent between call sites or versions.

That said it is still odd to me these produce different results and I would like to understand it as both version use the same runtime growslice logic. I suspect there is a subtile difference between the ssa append version for fixed number of elements: https://github.com/golang/go/blob/c489330987eca992cee0bb018a6fdb7ff5401704/src/cmd/compile/internal/gc/ssa.go#L2808

and the walk pass version: https://github.com/golang/go/blob/c489330987eca992cee0bb018a6fdb7ff5401704/src/cmd/compile/internal/gc/walk.go#L2705

if there isnt an error in the example itself.

seebs

comment created time in 19 days

IssuesEvent

issue commentgolang/go

runtime: opportunistically rotate map key seed

While https://golang.org/cl/253020 resets the seed when the map clear idiom is used it doesnt reset the seed when maps are emptied to zero elements by just deleting elements without ranging over all the keys or when the pattern for map clear is not triggered.

josharian

comment created time in 20 days

issue commentgolang/go

proposal: math: add package math/ints for common operations on integers

I think if this is added at all its better to wait for generics.

markusheukelom

comment created time in 23 days

IssuesEvent

issue closedgolang/go

x/mobile: Gomobile does not support ARMv7 builds for ios

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version go version go1.14.7 darwin/amd64

gomobile version gomobile version +973feb4 Sat Aug 1 11:21:45 2020 +0000 (android,ios); androidSDK=/Users/wsli/Library/Android/sdk/platforms/android-30

</pre>

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="/Users/wsli/go/bin" GOCACHE="/Users/wsli/Library/Caches/go-build" GOENV="/Users/wsli/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/wsli/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/Cellar/go/1.14.7/libexec" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/Cellar/go/1.14.7/libexec/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/0j/8lghc3kd7yx2c_1lp9zhc6_h0000gn/T/go-build149931103=/tmp/go-build -gno-record-gcc-switches -fno-common"

</pre></details>

What did you do?

gomobile bind -v -o $(BINDIR)/xxx.framework -target=ios

What did you expect to see?

frameworks support armv7

What did you see instead?

missing required architecture armv7

ld: warning: Could not find or use auto-linked framework

closed time in a month

basdevelop

issue commentgolang/go

x/mobile: Gomobile does not support ARMv7 builds for ios

As seen in the release notes Go 1.15 dropped darwin/arm support: https://golang.org/doc/go1.15#darwin

Issue for dropping support since new IOS versions do not support 32bit arm https://github.com/golang/go/issues/34751

basdevelop

comment created time in a month

issue closedgolang/go

strings: Add a function to get the nth rune in string

Is there any already?

closed time in a month

qlcom

issue commentgolang/go

strings: Add a function to get the nth rune in string

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues # Asking Questions

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For asking questions, see:

qlcom

comment created time in a month

issue commentgolang/go

x/sys/cpu: HasFMA should check HasOSXSAVE is true

You are right! The issue is the VEX prefix and 64bit and protected mode. So I guess we need to guard all vex prefixed instructions with a OSXSAVE check.

zhangyoufu

comment created time in a month

issue commentgolang/go

x/sys/cpu: HasFMA should check HasOSXSAVE is true

But why should it not be used with OSXSAVE? The FMA instruction uses xmm registers that are supported otherwise other SSE/SSE2 instructions wouldnt work either and the CPU says it supports FMA.

zhangyoufu

comment created time in a month

issue commentgolang/go

x/sys/cpu: HasFMA should check HasOSXSAVE is true

The instruction from the dump above that is faulting is: c4 e2 e1 b9 ca vfmadd231sd xmm1,xmm3,xmm2

This uses SSE registers so SSE (required) + FMA (HasFMA) should be enought. There are no AVX registers involved that would require OSXSAVE.

zhangyoufu

comment created time in a month

issue commentgolang/go

x/sys/cpu: HasFMA should check HasOSXSAVE is true

OSXSAVE is not related to MOVUPS. OSXSAVE is only required for AVX.

zhangyoufu

comment created time in a month

issue commentgolang/go

x/sys/cpu: HasFMA should check HasOSXSAVE is true

But what is CR4 on vista?

zhangyoufu

comment created time in a month

issue commentgolang/go

x/sys/cpu: HasFMA should check HasOSXSAVE is true

It seems reading CR4 is priviledged so likely Go wont be able to do that. There seems to be a windows API way to do this: https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getenabledxstatefeatures

If there is no easy way to check if Windows supports SSE from Go code and all supported Windows versions of Go work I dont think there will be a fix for this. SSE/SSE2 itself is supported by all amd64 compatible CPUs so it can only be the OS that doesnt support them on amd64.

zhangyoufu

comment created time in a month

issue commentgolang/go

x/sys/cpu: HasFMA should check HasOSXSAVE is true

What is the state of CR4.OSFXSR on Vista? (Note that OSFXSR is not OSXSAVE)

amd64 Go minimal requirement is SSE2. So if sse is not supported yes Go does not work (with or without FMA). The only action I would then see here is to check CR4.OSFXSR on go runtime start and if it is not set then stop right there independent of if FMA is used or not.

zhangyoufu

comment created time in a month

issue commentgolang/go

x/sys/cpu: HasFMA should check HasOSXSAVE is true

FMA can be used without using AVX registers which as far as I understand does not need OSXSAVE. So I think requiring OSXSAVE here is not the right fix as this would disallow code to use FMA with xmm (SSE) registers while the OS does not support saving ymm (AVX) registers.

I think to understand whats happening we need to disassemble go1.14.7 math_test.TestFMA and see what the instruction stream is that is the problem. Maybe VMWare pretends FMA is supported while it isnt but it doesnt seem to be an issue with OSXSAVE if this is reproducable to always error on the same PC.

Please run these two commands in /go1.14.7/src/math/ and post the output: go test -c go tool objdump -s "math_test.TestFMA" math.test

In addition does running: GODEBUG=cpu.fma=off go test in /go1.14.7/src/math/ work?

zhangyoufu

comment created time in a month

issue commentgolang/go

x/sys/cpu: HasFMA should check HasOSXSAVE is true

The above code uses FMA with an xmm register not with an ymm register it should therefore be fine unless Vista doesnt support SSE2.

Note that Windows XP/Vista is not supported by Go 1.14 and 1.15: https://golang.org/doc/install#requirements

To understand the actual issue please give the following information:

  • The output of go env
  • what is the CPU name and vendor that go is run on
  • the stack trace of the crash (so we can identify where the STATUS_ILLEGAL_INSTRUCTION is happening)
  • does this reproduce on Windows 7 or newer
zhangyoufu

comment created time in a month

issue commentgolang/go

x/sys/cpu: HasFMA should check HasOSXSAVE is true

Any useful code that uses FMA with ymm registers also needs to check for AVX (e.g. mov instructions to ymm). The HasAVX is only true one HasOSXSAVE is true.

FMA can also be used with xmm registers which does not require HasOSXSAVE.

zhangyoufu

comment created time in a month

issue closedgolang/go

go/list how to list available modules with new patch release

related to https://groups.google.com/forum/#!topic/golang-nuts/W7e8ugsipqI

Currently, I am not able to list new version of module but for patch only.

For example:

module github.com/test/test

go 1.15

require go.mongodb.org/mongo-driver v1.3.6

I want to know if a new patch version if available (here v1.3.7 and not v1.4.0), but I don't know how to do. The given example here https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies is for direct with minor and patch (I just want patch). And yet, the v1.3.7 has been released (https://pkg.go.dev/mod/go.mongodb.org/mongo-driver@v1.3.7).

$ go list -u -m all | grep "go.mongodb.org/mongo-driver"
go.mongodb.org/mongo-driver v1.3.6 [v1.4.0]

I want use this in my CI with psampaz/go-mod-outdated from @psampaz but only for patch version with something like :

go list -u -m -json all | go-mod-outdated -update -direct -style markdown -ci

What version of Go are you using (go version)?

1.5.0

closed time in a month

jerome-laforge

issue commentgolang/go

go/list how to list available modules with new patch release

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For venues to ask questions, see: https://github.com/golang/go/wiki/Questions

jerome-laforge

comment created time in a month

issue openedgolang/go

x/build: add builder that uses gccgo to bootstrap go gc

There have been issues now and in the past about bootstrapping Go gc from gccgo being broken #40855, #30771.

Documentation at https://golang.org/doc/install/source#bootstrapFromGccgo suggests that bootstraping from gccgo is supported.

If this is the case I suggest we add a builder for that. To not be blocked on ressources I would assume a build only linux/amd64 builder would suffice to catch bootstrap issues.

/cc @ianlancetaylor @dmitshur

created time in a month

issue commentgolang/go

Proposal: Go 2: add builtin function printf, sprint(/f/ln)

There are pros and cons to every change which need to be carefully evaluated.

To make it a full proposal please take the time to fill in the template so the thought and motivation behind the proposal is understood for discussion and evaluation. https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md

leaxoy

comment created time in a month

issue commentgolang/go

unicode: support version 13

I second the question: where is the procedure documented to generate the CL?

My motivation to knowing is not concerned with generating the update CL but more how to change the process to potentially generate more binary size efficient datastructures for the unicode package.

ainar-g

comment created time in a month

issue commentgolang/go

Proposal: Go 2: add builtin function printf, sprint(/f/ln)

@Howie66 Please use emoji voting on the orginal issue instead of comments to express sentiment on the proposal https://github.com/golang/go/wiki/NoPlusOne.

leaxoy

comment created time in a month

issue commentgolang/go

Proposal: add builtin function printf, sprint(/f/ln)

Can you explain why is this needed? Is it to save the one line to import "fmt" ?

leaxoy

comment created time in a month

issue commentgolang/go

cmd/compile: fatal error: textflag.h: No such file or directory

You have documentation claiming it is supported: https://golang.org/doc/install/source#bootstrapFromGccgo

Thanks for pointing that out. I open another ticket to investigate addition of build testers to make sure this is checked and not getting accidentially broken.

spackard

comment created time in a month

issue commentgolang/go

cmd/compile: fatal error: textflag.h: No such file or directory

Im not sure bootstrapping gc go with gccgo is supported. Has it worked before? Bootstrapping gc go with newer versions of gc go is supported (up from go 1.4).

spackard

comment created time in a month

issue commentgolang/go

Proposal: Go 2: the "watch" statement for easier error handling & more

With my change, most of your concerns are adressed:

To me now it looks even more like the abandoned handler/check proposal: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md

Could you please clarify what the main differences are that makes this proposal stand out it utility and avoiding problems vs the above proposal. This would help the discussion about the intent of the proposal and not reintroducing proposals that are (apart from minor details) the same. Minor details may be important so it is nice to understand the thought process behind them.

martinrode

comment created time in a month

issue commentgolang/go

Unable to reproduce the same gzip/DEFLATE compressed output as Python/Rust

Its unclear if this is a question how to change the Go code to make the output match or a proposal that the standard library produce the exact byte by byte output as some other tools for compression.

If it is a question please see https://github.com/golang/go/wiki/Questions for venues to ask questions.

If this is a proposal please clarify why this matters (assuming the current output is otherwise correct according to compression specifications) and why it should be aligned with Python and Rust. Are there other tools/programming languages that produce different output? Why not align with them?

evandrix

comment created time in a month

issue commentgolang/go

Proposal: Go 2: the "watch" statement for easier error handling & more

The proposal makes the "normal" control flow that previously was easy to detect by looking at return statements now hidden. Any assignment to a variable that is under "watch" can now exit the function.

var buf [4]byte
slice := buf[:]
watch buf, slice {
   ...
}
...
copy(buf[:], foo) // triggers watch?
copy(slice, foo) // triggers watch potentially exiting the function
...

There also a bunch of open question about behaviour that would need to be clarified:

  • what if a pointer to a variable is passed into another function. Is changing the value of the variable then triggering the watch even while in the other functions?
  • does another watch trigger when a value is assigned to a variable that is watched inside the watch itself?
  • can multiple watches be defined in a function?
  • can multiple watches be defined on the same variable?
  • are variable assignment in defers still watched? what defers are still executed if a watch triggers in defer?
  • what happens if a function closure is returned containing an assignment to a watched variable? Is the watch still active in the closure when returned or passed to a leave function, when called in the same function?
  • for multiple assignments (f1, f2 = ....) and a watch on f1, f2. Is the watch triggered once or twice?
martinrode

comment created time in a month

issue closedgolang/go

You are neither in a module nor in your GOPATH

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version

</pre>

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env

</pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

What did you see instead?

closed time in a month

youda-online

issue commentgolang/go

You are neither in a module nor in your GOPATH

There is nothing filled out in here to make this an actionable issue report.

youda-online

comment created time in a month

issue commentgolang/go

proposal: bytes: separate the package bytes into the Unicode-related part and the others

If the goal is to reduce binary size then I dont think just splitting bytes is worth the churn in either Go 1 or Go 2.

Many other packages strings, fmt, reflect will still require unicode to be imported making the number of go programs after the split not importing Unicode very small still.

The ergonomics when programming of having to reason in which package to find the corresponding bytes function that previously were all together in one package is I think not worth the 22k byte saved.

To tackle this problem for all packages I think (apart from avoiding adding unicode dependencies were possible) is to work on compiler and linker optimisations making the imported parts of unicode smaller. e.g. https://github.com/golang/go/issues/38784 This also has the advantage of not requiring Go 2 incompatibilities.

hajimehoshi

comment created time in a month

issue commentgolang/go

cmd/go: create zip: malformed file path: invalid char '→'

Please specify the exact commands and sourcecode used to reproduce the error. From the issue filed its unclear where go test was run and with which code.

ConnectionRefused

comment created time in a month

issue commentgolang/go

x/pkgsite: remove package from go dev website

/cc @julieqiu

ZiyaoQiao

comment created time in a month

issue closedgolang/go

GC test found very strange, do not understand

`package main

import ( "fmt" "runtime" "time" "unsafe" )

type ast struct { a int }

func (a *ast) free() { cnt++ fmt.Println("ast_free", unsafe.Pointer(a)) }

type bst struct { a *ast b **bst }

func (b *bst) free() { cnt++ fmt.Println("bst_free", unsafe.Pointer(b)) }

var cnt int

func testfreeCall2() { a := new(ast) b := new(bst) b.b = &b runtime.SetFinalizer(a, (*ast).free) runtime.SetFinalizer(b, (*bst).free)

b.a = new(ast)                         //Try to block this
runtime.SetFinalizer(b.a, (*ast).free) //Try to block this

fmt.Println("testfreeCall2__", unsafe.Pointer(a), unsafe.Pointer(b), unsafe.Pointer(b.a))

} func testfreeCall1() { a := new(ast) b := new(bst)

runtime.SetFinalizer(a, (*ast).free)
runtime.SetFinalizer(b, (*bst).free)
b.a = new(ast)
runtime.SetFinalizer(b.a, (*ast).free)

fmt.Println("testfreeCall1__", unsafe.Pointer(a), unsafe.Pointer(b), unsafe.Pointer(b.a))

}

func main() {

//testfreeCall1() //+3
testfreeCall2() //+1
//testfreeCall2() //+1
testfreeCall1() //+3

time.Sleep(1000 * 1000 * 100)
for i := 0; i < 5; i++ {
	runtime.GC()
	fmt.Println("status:", cnt, i)
	time.Sleep(1000 * 1000 * 100)
}

fmt.Println("exit")

} `

closed time in a month

ruyi789

issue commentgolang/go

GC test found very strange, do not understand

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

See https://github.com/golang/go/wiki/Questions for ressources to ask questions.

ruyi789

comment created time in a month

issue closedgolang/go

adamlaska

Mining

closed time in a month

adamlaska

issue commentgolang/go

runtimer: bad p & random crashes since 1.14

https://www.kernel.org/category/releases.html seems to suggest 3.18.11 is not supported anymore and quite old. So im not sure how effective it will be finding the bug and if it is on the linux side it may likely not get fixed. There may however be interest in learning what the issue is and if it could be reproduced on newer kernels (or reintroduced if not careful) if it isnt related to a known issue like: #35777

gwillem

comment created time in a month

issue commentgolang/go

runtimer: bad p & random crashes since 1.14

I think the next step is to figure out why async preemption interacts badly with the 3.18.11 kernel here.

For now you can programmatically disable asyncpreemption for now by setting GODEBUG=asyncpreemptoff=1 in your systems environment.

gwillem

comment created time in a month

issue commentgolang/go

Proposal: disallow Hangul filler codepoints in Go identifiers

Relevant issue about homographs attacks: https://github.com/golang/go/issues/20115

dolmen

comment created time in a month

issue commentgolang/go

import cycle not allowed

I cant build minikube due to other reasons.

$ git clone https://github.com/kubernetes/minikube
$ cd minikube/cmd/minikube/
$ go build
# k8s.io/minikube/pkg/minikube/translate
../../pkg/minikube/translate/translate.go:80:12: undefined: Asset

how was the code in /Users/ouyangbin/Downloads/source_code/minikube-master/ obtained?

oyb001

comment created time in a month

issue commentgolang/go

runtimer: bad p & random crashes since 1.14

Wild guess could be https://github.com/golang/go/issues/35777 ? Try running with GODEBUG=asyncpreemptoff=1 and see if that avoids the crashes.

gwillem

comment created time in a month

issue commentgolang/go

proposal: cmd/vet: warn about variables/values of type reflect.{Slice,String}Header

Making it a compiler error will be a hard stop to this. On the other side these code instances will lead to subtle memory corruption bugs that need the right circumstances come together and may not be caught by tests just checking for correct output values of the functioncs involved. They can be hard to diagnose which could justify this.

mdempsky

comment created time in a month

issue commentgolang/go

proposal: cmd/vet: warn about variables/values of type reflect.{Slice,String}Header

Unfixed example in the wild: https://github.com/alecthomas/unsafeslice/issues/4 Corresponding static check proposal: https://github.com/dominikh/go-tools/issues/782

mdempsky

comment created time in a month

issue commentgolang/go

cmd/compile: improve inlining cost model

Because the fact that it doesn't inline range loops, then if I call memset(s, 0) it will call to memset and then loop instead of just calling to runtime.memclrNoHeapPointers which it could've done if it new that c=0

I dont think the existing range clear optimizations will trigger even if the inlining is changed. Thats something that will not only need inlining but the range clear optimization to move after some ssa pass optimizations that propagate that c is a constant.

Best short term bet is to write it directly:

josharian

comment created time in a month

issue commentgolang/go

proposal: Go 2: allow & as l-value operator

To me having all unary operators also on the left side impairs readability as the operation on both left and right side need now be merged mentally to understand how the value of an expression assigned is computed. They might also be visually much further away the current examples. * is special in that regard as it only signifies where to store a value unmodified.

arnottcr

comment created time in a month

issue commentgolang/go

proposal: all: drop GO386=387 support in Go 1.16

The most feedback to keep support seems to come from users with AMD Geode GX/LX (the kind with MMX but not SSE or SSE2) boards still used in the embedded space/routers.

Im in favor of dropping 387. As an alternative go1.16 could be made to reinterpret GO386=387 to mean use softfloat support instead of 387 or SSE2 instructions. This would make ordinary go programs on 387 hardware still work, but slower. It would make the register based calling conventions still easier as other platforms (e.g. arm and mips) also require softfloat support. We would also have a mainstream platform for builders to test the softfloat code paths frequently. The upside is that e.g. Athlon XP and Pentium III keep on working and distros dont need to switch away from go gc to gogcc for their package builders for 386 distros supporting old hardware.

For verifying no newer instructionsets are used we could potentially use something like: https://software.intel.com/content/www/us/en/develop/articles/intel-software-development-emulator.html

aclements

comment created time in a month

issue commentgolang/go

cmd/compile: add support for compiling without the MMX requirement on GOARCH=386

https://github.com/ish-app/ish/issues/57 has been closed by ish-app supporting MOVQ now: https://github.com/ish-app/ish/commit/e898efeacf3f0f2b97fe2748d1fd86d0130f59de

Can this issue be closed?

b-

comment created time in a month

issue commentgolang/go

proposal: Go 2: use keywords throw, catch, and guard to handle errors

The analyzer can tell you are passing function foo that can throw to function fmt.Printf that doesn't have catch to handle the throw.

The analyzer can not know that in all cases if e.g. foo being an interface{} value that came from somewhere populated at run time.

ysmood

comment created time in 2 months

issue commentgolang/go

proposal: Go 2: use keywords throw, catch, and guard to handle errors

reflect can call normal functions just fine there is not constraint in the proposal or language that forbids functions called with reflect.Call to need to use reflect.Throw

ysmood

comment created time in 2 months

issue commentgolang/go

proposal: Go 2: use keywords throw, catch, and guard to handle errors

I think it's the same as Go1's error. If you return an error as an interface, it will be hard to tell when a function will return an error or not.

True but there was no claim here that its possible to know where all error values are originating from either. Errors dominately are returned as error types directly which is possible to analyse statically and not as interface{}. This analysis also doesnt need whole program inter package analysis as knowing function signatures is enough. As there would be no explicit annotation for throws the analysis is quite a bit harder and has more commonly used language cases like function variables and reflect Calls where it will expensive or not knowable if a throw can happen.

ysmood

comment created time in 2 months

issue commentgolang/go

proposal: Go 2: use keywords throw, catch, and guard to handle errors

It's very easy to recursively analyze the code to know if a throw is not caught by any catch.

This is not possible statically when reflect Call, function variables and plugins are involved without explicit anotation.

ysmood

comment created time in 2 months

issue commentgolang/go

proposal: iterators

"is that existing builtin types that are iterable can automatically implement the iterator interface"

I think it needs to be spelled out what this means. How can []int implement the iterator interface? Does that mean []int would have a Next method which is a fairly invasive language change for all types now to have methods. Also next requires a state. How and when is this intialized/reset for a value like []int{1,2,3} ?

Would e.g. range use that iterator interface? Why not? If yes how?

Zaba505

comment created time in 2 months

issue commentgolang/go

proposal: spec: use (*[4]int)(x) to convert slice x into array pointer

Sure its already possible to use a copy. Not meaning to imply it was compelling. The compiler currently zeros key, then copies in strs with a typedslicecopy then moves the contents to a tmp and passes a pointer to the tmp copy to the runtime map routine. Ideally (which might be easier to optimize by the compiler) it would just pass a pointer to the backing array of the strs slice.

https://godbolt.org/

rogpeppe

comment created time in 2 months

issue commentgolang/go

proposal: spec: use (*[4]int)(x) to convert slice x into array pointer

Anecdotal story for when I would like to have used this:

I was working on an optimization for a hot library code path. It was using a string as key to a map. That string got constructed by a strings.Join from a []string. For all practical purposes they were always 4 elements long. Due to historical reasons and generality the functions involved used a []string as input and changing this as it was a widely used API and config would have introduced alot of effort and churn in a large codebase.

Using [4]string as a map key (with a fallback for the case where it could have been used otherwise by joining the down to only using the first element of [4]string with a special terminal symbol) was a bit faster as it avoid an allocation to construct the string key. However there is no safe way to just convert []string to [4]string (or *[4]string) without copying [4]string (or allocating) which made the new code a bit slower then it needed to be.

Code that i liked to have ideally written for performance would have been (simplified):

if len(strs) == 4 {
   v := m[*(*[4]string)(strs)]
}

Googlers: Search for the phrase "In practice, entries always have four components" in the mono repo.

rogpeppe

comment created time in 2 months

issue closedgolang/go

G0

closed time in 2 months

to75988070

issue commentgolang/go

proposal: cmd/go: deprecate direct fallback in GOPROXY

Furthermore, it is inconcevable that, for the default values, one could reach sum.golang.org, but not proxy.golang.org.

Im certain if given the access controls or due to the right set of circumstance to disable traffic to proxy.golang.org while sum.golang.org will be fine.

since they are the same service. They may or may not be currently. They dont have to be in the future and they dont have to use the same load balancer config.

arnottcr

comment created time in 2 months

issue commentgolang/go

https://tour.golang.org/welcome/2

Can you give a link to the russian tutorial that doesnt work?

Fenimorkin

comment created time in 2 months

issue commentgolang/go

proposal: cmd/go: deprecate direct fallback in GOPROXY

There is still the possibility of the go proxy being unavailble while the sumdb is not. And the proxy might not have the module or be able to fetch the module while the sumdb already knows about it. Its nice to have a usable fallback to improve overall reliability.

arnottcr

comment created time in 2 months

issue commentgolang/go

proposal: cmd/go: deprecate direct fallback in GOPROXY

Isnt there the possibility of companies running their own internal sum db with internal url set in GOSUMDB? This does not require that the external proxy has the same visibility to packages as the internal sum db server.

arnottcr

comment created time in 2 months

issue commentgolang/go

errors: As can loop endlessly

Test should be able to detect that there is a bad loop and time out. At which point the code causing the loop will be detected and can be fixed by the programmer.

If we put a limit on the depth it will be too low for some and to large (oom before reaching the limit) for others. An existing case similar to the problem is that fmt Stringer can get into an infinite recursion too.

rolandshoemaker

comment created time in 2 months

issue commentgolang/go

proposal: Go 2: use keywords throw, catch, and guard to handle errors

See https://github.com/golang/go/issues/40432.

Especially: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md For why implicit checking/implicit results is not prefered for error handling.

ysmood

comment created time in 2 months

issue commentgolang/go

proposal: allow fallthrough in type switches

large switch cases already impact readability to me with or without fallthrough. the new example is better dealt with in my mind with (function names to be adjusted to reflect actual use better):

switch t := v.(type) {
case pkg.One:
        processPkgOne(&t)
case *pkg.One:
        processPkgOne(t)
case pkg.Two:
        processPkgTwo(&t)
case *pkg.Two:
        processPkgTwo(t)        
case []byte:
        var d pkg.Data
        json.Unmarshal(t, &d)
        processPkgData(d)
case pkg.Data:
        processPkgData(t)
}

Same number of lines on the screen and I do not have to deal with the concept of fallthrough changing into the next block. Each block can be changed and removed without impacting any other block.

If the statements in each block are short and trivial (e.g. 1-3 lines) some lines can just be duplicated (as we save the fallthrough line) without taking up much more space. If the functionality is complex and common likely using a function makes sense for better testability. Has the added advantage that it can be used for any block in the switch case.

Another question would be why if *pkg.One and pkg.One behave the same can this is not be abstracted in an interface (which may also apply to pkg.Two) and all the cases together can be dealt with one interface conversion.

carnott-snap

comment created time in 2 months

issue commentgolang/go

proposal: allow fallthrough in type switches

Is there any expression allowed after fallthrough as long as its assignable to the type of t in the next case block?

carnott-snap

comment created time in 2 months

more