Re: [go-nuts] GoLLVM: using the result of `go build -x . ` to rebuild the program got failed

Thanks. What I meant was that you showed us the errors from the generated shell script, but you didn't show us the commands being run by the shell script that generated those errors. Trying running the script with the -x option. Ian On Thu, Oct 27, 2022, 7:05 PM 'Qingwei Li' via golang-nuts < g

Re: [go-nuts] What's the maximum array length?

On Thu, Oct 27, 2022 at 9:16 PM Rob Pike wrote: > For those watching at home, the error message is > > compile: data too large > Yes, but as I noted in my reply if you remove the composite literal initializer (i.e., reducing it to just var x = [1 << 34]byte{}) I get this error (using Go 1.19 on

Re: [go-nuts] What's the maximum array length?

Ah, and here's why. cmd/internal/obj/objfile as a 32-bit data size. if int64(uint32(dataOff)) != dataOff { log.Fatalf("data too large") } On Fri, Oct 28, 2022 at 3:15 PM Rob Pike wrote: > For those watching at home, the error message is > > compile: data too large > > -rob > > > > On Fri,

Re: [go-nuts] What's the maximum array length?

For those watching at home, the error message is compile: data too large -rob On Fri, Oct 28, 2022 at 12:43 PM eric...@arm.com wrote: > The spec says that " The length is part of the array's type; it must > evaluate to a non-negative constant > representab

Re: [go-nuts] GoLLVM: using the result of `go build -x . ` to rebuild the program got failed

commands I executed are as follows. ```bash go build -x . 2> auto.sh # get the building process rm easyPkg # remove the binary file go clean -cache # clean the cache for rebuilding source auto.sh # rebuild ``` the llvm-project is built by following instructions in section "On Unix-like Systems

Re: [go-nuts] GoLLVM: using the result of `go build -x . ` to rebuild the program got failed

go version go1.18 gollvm LLVM 15.0.0git 20220823 (experimental) linux/amd64 I might have replied to you only, because the post is not shown on the discussion. 在2022年10月28日星期五 UTC+8 00:11:27 写道： > >/data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized > command line option '-fgo-

[go-nuts] What's the maximum array length?

The spec says that " The length is part of the array's type; it must evaluate to a non-negative constant representable by a value of type int. ", so on a 64-bit environment, I assume that the maximum array length sho

[go-nuts] fmt.Formatter and '%w'

you can use the fmt.Formatter interface to make your own 'verbs', makes sense as expected, except for 'w' where you just get the error: > fmt.Printf format %w has arg ??? of wrong type seems trying to make your own formatting for the verb 'w' is blocked, presumably because it checks for an i

Re: [go-nuts] 1.19.2: gofmt fails on CI but not locally

Your CI environment is running go generate ./... and the column number reported by gofmt doesn't make any sense for the file you linked to. So the obvious conclusion is that either the blob you linked to is out of date and you'll see the problem locally if you run go generate ./... first, or genera

[go-nuts] 1.19.2: gofmt fails on CI but not locally

Really strange issue, have been scratching my head for hours now. Consider https://github.com/evcc-io/evcc/blob/0b8105d36d245a2169961c48e50fbb830fd38147/charger/ocpp_decorators.go. Absolutely fine imho. Yet gofmt fails, but only on CI: https://github.com/evcc-io/evcc/actions/runs/3340736849/jo

Re: [go-nuts] What's the consensus these days on dealing with defer errors?

> On 2022. Oct 27., at 20:16, Konstantin Khomoutov wrote: > > On Thu, Oct 27, 2022 at 11:01:01AM -0700, Gergely Brautigam wrote: > > [...] >>> Since Go 1.13 you can also make chains of errors; say, in your second >>> example >>> you could do >>> >>> err = fmt.Errorf("doSomething failed wi

Re: [go-nuts] What's the consensus these days on dealing with defer errors?

On Thu, Oct 27, 2022 at 11:01:01AM -0700, Gergely Brautigam wrote: [...] > > Since Go 1.13 you can also make chains of errors; say, in your second > > example > > you could do > > > > err = fmt.Errorf("doSomething failed with %s while handling %w", > > tmpErr, err) > > > > and then have calle

Re: [go-nuts] What's the consensus these days on dealing with defer errors?

Interesting, the chaining is a nice idea. However, wouldn't that mean that I would still have to errors.Is a specific error. So I would have to handle both. Which is fine ofc. Just saying. :) On Thursday, 27 October 2022 at 19:51:14 UTC+2 Konstantin Khomoutov wrote: > On Thu, Oct 27, 2022 at 06

Re: [go-nuts] What's the consensus these days on dealing with defer errors?

On Thu, Oct 27, 2022 at 06:23:31AM -0700, Gergely Brautigam wrote: > I was wondering what's the consensus these days on handling defer errors? > > Is it something like, overwriting the returned value, or using a list of > errors? > > Either: > > func test() (err error) { > defer func() { >

Re: [go-nuts] GoLLVM: using the result of `go build -x . ` to rebuild the program got failed

On Thu, Oct 27, 2022 at 9:11 AM 'Than McIntosh' via golang-nuts wrote: > > >/data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized command > >line option '-fgo-importcfg=/dev/null' > > The Go command only passes this option to the compiler if it thinks that the > compiler is the ma

Re: [go-nuts] Integration testing program that internally forks itself

Any recursion that does not have a terminating condition will try to recurse infinitely ;-) I'm passing a command line flag in such situations - when testing, but the best option depends on the particular use. Elsewhere, in a command that starts a server or talks to the server, I used, for example

Re: [go-nuts] GoLLVM: using the result of `go build -x . ` to rebuild the program got failed

>/data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized command line option '-fgo-importcfg=/dev/null' The Go command only passes this option to the compiler if it thinks that the compiler is the main go compiler ("gc") as opposed to gollvm. What output do you get when you run "go ve

[go-nuts] Integration testing program that internally forks itself

We have a program that forks itself in order to do some work so calling `./program do` internally finds its path using os.Executable and calls `./program do2` Now when trying to do integration tests program spawns itself and repeats test causing an infinite loop? Any ideas how to handle it? --

[go-nuts] GoLLVM: using the result of `go build -x . ` to rebuild the program got failed

the GoLLVM is based on LLVM 15.0.0 Example to reproduce: The structure of project is as follows: ``` easyPkg/ ├── go.mod ├── main.go └── Pkg └── utils.go ``` main.go ``` package main import "easyPkg/Pkg" func main() { Pkg.PkgFunc() } ``` utils.go ``` package Pkg func PkgFunc() {

[go-nuts] What's the consensus these days on dealing with defer errors?

Hello, esteemed Gophers. I was wondering what's the consensus these days on handling defer errors? Is it something like, overwriting the returned value, or using a list of errors? Either: func test() (err error) { defer func() { if tmpErr := doSomething(); tmpErr != nil {

Re: [go-nuts] what is the origin of Go's reference time system?

* Ayan George [221026 13:51]: > > I'm really impressed by the simplicity of Go's time formatting and parsing > mechanisms -- particularly when compared with strftim(). I have to disagree. This is the most egregious design flaw of the standard library, and the second worst design flaw of the la

[go-nuts] Re: First stable version of several package under golang.org/x/

Thank you for the detailed answer! Indeed this may not warrant any announcement, just wanted to be sure I wasn't missing something! :sweat_smile: I'll follow that closely. Thanks! On Thursday, October 27, 2022 at 2:10:15 AM UTC+2 Heschi Kreinick wrote: > Yeah, text and tools were already tagge

Re: [go-nuts] Analyse postgresql error

Thanks. Exactly what I needed. On Wed, Oct 26, 2022 at 3:45 PM Konstantin Khomoutov wrote: > On Wed, Oct 26, 2022 at 01:38:51PM +0300, David Harel wrote: > > [...] > > func errorCheckResult(err error) string { > > if err == nil { > > return "" > > } > > pqerr := err.(*pq.Erro