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

[Kurtis Rader]

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 macOS):

./x.go:3:5: main.x: symbol too large (17179869184 bytes > 20 bytes)

That appears to be the primary limit. That including a composite literal
initializer that exceeds that limit, causing a more ambiguous error, seems
like a related, but secondary, issue.


> 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 
>> representable  by a value of
>> type int. ", so on a 64-bit environment, I assume that the maximum array
>> length should be math.MaxInt64, am I right ? But the following code doesn't
>> compile:
>>
>> package main
>> var x = [1<<34]byte{1<<23: 23, 1<<24: 24, 1<<33:33
>>
>>
-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD-QnJbRS3Vj-LWXKePOp2Q3FGi15tpEOhFbd2%3Df%3D5fEfQ%40mail.gmail.com.

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

[Rob Pike]

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, 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 
>> representable  by a value of
>> type int. ", so on a 64-bit environment, I assume that the maximum array
>> length should be math.MaxInt64, am I right ? But the following code doesn't
>> compile:
>>
>> package main
>> var x = [1<<34]byte{1<<23: 23, 1<<24: 24, 1<<33:33}
>>
>> --
>> 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/e295dd1c-2abd-4709-a6c4-1252ef635b5en%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/CAOXNBZQsnk%3DyD0jCd4Fo1h1Y4q_7msHzi7WhQtgQnBi9HrDtSA%40mail.gmail.com.

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

[Rob Pike]

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 
> representable  by a value of
> type int. ", so on a 64-bit environment, I assume that the maximum array
> length should be math.MaxInt64, am I right ? But the following code doesn't
> compile:
>
> package main
> var x = [1<<34]byte{1<<23: 23, 1<<24: 24, 1<<33:33}
>
> --
> 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/e295dd1c-2abd-4709-a6c4-1252ef635b5en%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/CAOXNBZQWRB-iAdZ2KHV2TxEWBywg7BjpijS9pWC0PBL_OZk8FQ%40mail.gmail.com.

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

['Qingwei Li' via golang-nuts]

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 > Build LLVM and Clang:" 
in https://clang.llvm.org/get_started.html
and replace "Unix Makefiles" with "Ninja" and "make" with "ninja"

LLVM version is 15.0.0

gollvm version is

```
go version go1.18 gollvm LLVM 15.0.0git 20220823 (experimental) linux/amd64
```

在2022年10月28日星期五 UTC+8 00:55:03 写道：

> 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 main go compiler ("gc") as opposed to gollvm. What 
> output do you get when you run "go version" ?
>
> The code is testing whether the compiler supports that option. The
> errors about -fgo-importcfg and -ffile-prefix-map can be ignored.
>
> Not sure what is happening elsewhere, though. You showed the output
> but not the commands.
>
> Ian
>
>
>
> > On Thu, Oct 27, 2022 at 12:05 PM 'Qingwei Li' via golang-nuts <
> golan...@googlegroups.com> wrote:
> >>
> >> 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() {
> >> println("pkgFunc")
> >> }
> >> ```
> >>
> >> go.mod
> >>
> >> ```
> >> module easyPkg
> >>
> >> go 1.18
> >> ```
> >>
> >> use `go build -x . 2> auto.sh` to get the building process. Then delete 
> the generated binary file `easyPkg` and use `go clean -cache` to clean the 
> building cache. Then I use the command `source auto.sh` to regenerate the 
> binary, which fails.
> >>
> >> part of the error log is as follows
> >>
> >> ```
> >> /data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized 
> command line option '-fgo-importcfg=/dev/null'
> >> /data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized 
> command line option '-ffile-prefix-map=a=b'
> >> ./main.go:3:19: error: 
> /tmp/go-build3415416681/b001/_importcfgroot_/easyPkg/libPkg.a exists but 
> does not contain any Go export data
> >> ./main.go:3:19: warning: easyPkg/Pkg: Not a directory
> >> ./main.go:3:19: error: import file 'easyPkg/Pkg' not found
> >> ./main.go:6:2: error: reference to undefined name 'Pkg'
> >> /usr/bin/ld.gold: error: /tmp/go-build3415416681/b001/_pkg_.a: member 
> at 72 is not an ELF object
> >> /usr/bin/ld.gold: error: /tmp/go-build3415416681/b002/_pkg_.a: member 
> at 72 is not an ELF object
> >> buildid: open /tmp/go-build3415416681/b001/exe/a.out: no such file or 
> directory
> >> ```
> >>
> >> what can I do on the auto.sh script to regenerate the binary file? Is 
> the process dumped completed?
> >>
> >> On a single package with no subdirectory, the result of `go build -x .` 
> is available for regenerating the binary file.
> >>
> >> Moreover, my main purpose is to add -emit-llvm option wherever 
> `llvm-goc` appears and use `llvm-link -S` to link all object files 
> generated by llvm-goc to get a whole LLVM IR file for the whole project. If 
> the question above is now insoluble, is there any other way to get the 
> whole project's LLVM IR?
> >>
> >>
> >> --
> >> 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...@googlegroups.com.
> >> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/b120de38-d603-4a8d-a029-34351abc051cn%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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55ENsDS_zpp0TCeyJDfh7jO%2B%3DQOcrfNs1zxqNBYjpPPvDw%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/193d828b-1f57-4cf9-a661-849127823d0dn%40googlegroups.com.

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

['Qingwei Li' via golang-nuts]

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-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 version" ?
>
> Thanks, Than
>
>
> On Thu, Oct 27, 2022 at 12:05 PM 'Qingwei Li' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> 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() {
>> println("pkgFunc")
>> }
>> ```
>>
>> go.mod
>>
>> ```
>> module easyPkg
>>
>> go 1.18
>> ```
>>
>> use `go build -x . 2> auto.sh` to get the building process. Then delete 
>> the generated binary file `easyPkg` and use `go clean -cache` to clean the 
>> building cache. Then I use the command `source auto.sh` to regenerate the 
>> binary, which fails.
>>
>> part of the error log is as follows
>>
>> ```
>> /data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized 
>> command line option '-fgo-importcfg=/dev/null'
>> /data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized 
>> command line option '-ffile-prefix-map=a=b'
>> ./main.go:3:19: error: 
>> /tmp/go-build3415416681/b001/_importcfgroot_/easyPkg/libPkg.a exists but 
>> does not contain any Go export data
>> ./main.go:3:19: warning: easyPkg/Pkg: Not a directory
>> ./main.go:3:19: error: import file 'easyPkg/Pkg' not found
>> ./main.go:6:2: error: reference to undefined name 'Pkg'
>> /usr/bin/ld.gold: error: /tmp/go-build3415416681/b001/_pkg_.a: member at 
>> 72 is not an ELF object
>> /usr/bin/ld.gold: error: /tmp/go-build3415416681/b002/_pkg_.a: member at 
>> 72 is not an ELF object
>> buildid: open /tmp/go-build3415416681/b001/exe/a.out: no such file or 
>> directory
>> ```
>>
>> what can I do on the auto.sh script to regenerate the binary file? Is the 
>> process dumped completed?
>>
>> On a single package with no subdirectory, the result of `go build -x .` 
>> is available for regenerating the binary file.
>>
>> Moreover, my main purpose is to add -emit-llvm option wherever `llvm-goc` 
>> appears and use `llvm-link -S` to link all object files generated by 
>> llvm-goc to get a whole LLVM IR file for the whole project. If the question 
>> above is now insoluble, is there any other way to get the whole project's 
>> LLVM IR?
>>
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/b120de38-d603-4a8d-a029-34351abc051cn%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/9ee5ffe6-7394-4317-8767-c7d9c321e1een%40googlegroups.com.

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

[eric...@arm.com]

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 should be math.MaxInt64, am I right ? But the following code doesn't 
compile:

package main
var x = [1<<34]byte{1<<23: 23, 1<<24: 24, 1<<33:33}

-- 
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/e295dd1c-2abd-4709-a6c4-1252ef635b5en%40googlegroups.com.

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

['simon place' via golang-nuts]

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 implementer of the Error interface 
before checking for the fmt.Formatter interface, seems inconsistent and 
unfortunate. maybe a bug?

-- 
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/a5babc0a-bb3d-4b3e-93cb-2942e109231bn%40googlegroups.com.

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

[Kurtis Rader]

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
generating that content in the CI environment is producing different output
for some reason.

On Thu, Oct 27, 2022 at 1:47 PM cpu...@gmail.com  wrote:

> 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/jobs/5531173685
> with
>
> gofmt -w -l $(find . -name '*.go')
> Error: ./charger/ocpp_decorators.go:9:186: expected declaration, found ')'
>
> I can't find any reason why this should fail and it doesn't do so locally.
>
> Any idea would be welcome as that CR has been stuck due to gofmt.
>
>
> --
> 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/8a2e6351-b88a-46ff-917b-af9110aa8aaan%40googlegroups.com
> 
> .
>


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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD_GsgpPeaKVtGc5Wv-bco5HPAeJpbuyTDkttQ77%2BAYXWQ%40mail.gmail.com.

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

[cpu...@gmail.com]

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/jobs/5531173685 
with

gofmt -w -l $(find . -name '*.go') 
Error: ./charger/ocpp_decorators.go:9:186: expected declaration, found ')'

I can't find any reason why this should fail and it doesn't do so locally.

Any idea would be welcome as that CR has been stuck due to gofmt.


-- 
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/8a2e6351-b88a-46ff-917b-af9110aa8aaan%40googlegroups.com.

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

[Gergely Brautigam]

> 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 with %s while handling %w", 
>>> tmpErr, err) 
>>> 
>>> and then have callers use errors.Is / errors.As or whatever other approach 
>>> to 
>>> learn whether the error of their interest is in the error chain. 
>>> 
>>> Note that in ether approach with returning multiple errors, the callers 
>>> are to 
>>> be prepared to handle multiple errors; otherwise it's engineering for the 
>>> sake 
>>> of engineering which leads to nothing more than code which is convoluted 
>>> for 
>>> nothing. 
> [...]
> 
>> 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. :)
> 
> Chaining is good in the sense you can still consider a chain to be a single
> error, and only inspect the chain when there is need for that.
> 
> The usual case for this approach is that when some operation involving
> multiple nested calls happens, some deep one fails, then each level wraps the
> error in its own context as the error bubbles up the stack.
> Then at the call site you have an error with properly nested contexts in the
> message - like in "failed to X: error frobincating Y: fizzling of bar
> failed: Z: error while fooing quux: ... and so on", and you can just log it
> and have a full actionable error message in the logs. And at the same time
> you can inspect the chain if you need special processing in case, say,
> fooing of quux failed, but not in other cases. With chaining, you can do this,
> while still passing the whole chain around where the rest of the code does not
> care about whether it is really a chain or a "simple" error.

Nice! I really like this idea. :) Thank you very much for sharing it. :)

-- 
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/E76397EE-A9A9-4BF3-B7DF-DC9DF65E25F8%40gmail.com.

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

[Konstantin Khomoutov]

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 callers use errors.Is / errors.As or whatever other approach 
> > to 
> > learn whether the error of their interest is in the error chain. 
> >
> > Note that in ether approach with returning multiple errors, the callers 
> > are to 
> > be prepared to handle multiple errors; otherwise it's engineering for the 
> > sake 
> > of engineering which leads to nothing more than code which is convoluted 
> > for 
> > nothing. 
[...]

> 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. :)

Chaining is good in the sense you can still consider a chain to be a single
error, and only inspect the chain when there is need for that.

The usual case for this approach is that when some operation involving
multiple nested calls happens, some deep one fails, then each level wraps the
error in its own context as the error bubbles up the stack.
Then at the call site you have an error with properly nested contexts in the
message - like in "failed to X: error frobincating Y: fizzling of bar
failed: Z: error while fooing quux: ... and so on", and you can just log it
and have a full actionable error message in the logs. And at the same time
you can inspect the chain if you need special processing in case, say,
fooing of quux failed, but not in other cases. With chaining, you can do this,
while still passing the whole chain around where the rest of the code does not
care about whether it is really a chain or a "simple" error.

-- 
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/20221027181557.tgwbqniwnegusky6%40carbon.

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

[Gergely Brautigam]

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: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() { 
> > if tmpErr := doSomething(); tmpErr != nil { 
> > err = tmpErr 
> > } 
> > }() 
> > 
> > err = doSomethingElse() 
> > return err 
> > } 
> > 
> > Or: 
> > func test() (errList []error) { 
> > defer func() { 
> > if tmpErr := doSomething(); tmpErr != nil { 
> > errList = append(errList, tmpErr) 
> > } 
> > }() 
> > 
> > if err := doSomethingElse(); err != nil { 
> > errList = append(errList, err) 
> > } 
> > return errList 
> > } 
> > 
> > Or even something else entirely? 
>
> I think you're falling into a common trap: there's no need to have any 
> sort of 
> consensus here because what you have demonstrated are two approaches to 
> tackle 
> a problem, and they depend on what you're after. 
>

Sure, I was merely trying to ascertain what other people are doing in this 
area. :)
 

>
> One could easily add other variations. 
>

For sure, just simply logging the error is also an option.
 

>
> For instance, often you want to Close() a resource on an error path out; 
> calling Close might itself return an error, and sometimes this error is 
> less 
> severe than the "original" one. As an example, consider opening a network 
> socket and then doing some setup on it: say, socket creation went OK but 
> the 
> setup failed, so you'd want to return the error about the failed setup 
> operation, and if closing the socket on the way out fails for some reason, 
> you could possibly ignore this error. Of may be you can log it. 
>
> On the other hand, if, say, you had a file opened for writing, wrote some 
> data 
> to it, then some error has happened, and you're aborting the operation 
> returning that error, and closing of the file on the way out fails, this 
> might 
> be a severe enough error because it might indicate some data which was 
> written 
> got lost. What to do about it? There's no ready answer. You could 
> construct a 
> custom error with a compound error message, like "error X has happened 
> while 
> Y, and also closing of F has failed during cleanup". 
>

Right, you could indeed return a compound error that contains the 
"ClosingError" 
or something like that. That's also a nice idea. :)
 

>
> You can also return a list of errors. 
> Or create a custom type implenting the error interface which holds a list 
> of 
> errors. 
>
> 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 callers use errors.Is / errors.As or whatever other approach 
> to 
> learn whether the error of their interest is in the error chain. 
>
> Note that in ether approach with returning multiple errors, the callers 
> are to 
> be prepared to handle multiple errors; otherwise it's engineering for the 
> sake 
> of engineering which leads to nothing more than code which is convoluted 
> for 
> nothing. 
>
> So I'd recommend to start small, use the simplest approach possible until 
> you 
> see clear need to use a more complex one, and then decide what looks/works 
> best in a particular case. I know, this is a glib piece of advice, but 
> it's 
> really how the things are ;-)
>

Sure, that's fine. :) I was just trying to gauge what people use.
 

-- 
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/1c365b80-4986-4f9c-9f77-7adf5ced894bn%40googlegroups.com.

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

[Konstantin Khomoutov]

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() {
> if tmpErr := doSomething(); tmpErr != nil {
> err = tmpErr
> }
>  }()
> 
>  err = doSomethingElse()
>  return err
> }
> 
> Or:
> func test() (errList []error) {
> defer func() {
> if tmpErr := doSomething(); tmpErr != nil {
> errList = append(errList, tmpErr)
> }
>  }()
> 
>  if err := doSomethingElse(); err != nil {
>   errList = append(errList, err)
>  }
>  return errList
> }
> 
> Or even something else entirely? 

I think you're falling into a common trap: there's no need to have any sort of
consensus here because what you have demonstrated are two approaches to tackle
a problem, and they depend on what you're after.

One could easily add other variations.

For instance, often you want to Close() a resource on an error path out;
calling Close might itself return an error, and sometimes this error is less
severe than the "original" one. As an example, consider opening a network
socket and then doing some setup on it: say, socket creation went OK but the
setup failed, so you'd want to return the error about the failed setup
operation, and if closing the socket on the way out fails for some reason,
you could possibly ignore this error. Of may be you can log it.

On the other hand, if, say, you had a file opened for writing, wrote some data
to it, then some error has happened, and you're aborting the operation
returning that error, and closing of the file on the way out fails, this might
be a severe enough error because it might indicate some data which was written
got lost. What to do about it? There's no ready answer. You could construct a
custom error with a compound error message, like "error X has happened while
Y, and also closing of F has failed during cleanup".

You can also return a list of errors.
Or create a custom type implenting the error interface which holds a list of
errors.

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 callers use errors.Is / errors.As or whatever other approach to
learn whether the error of their interest is in the error chain.

Note that in ether approach with returning multiple errors, the callers are to
be prepared to handle multiple errors; otherwise it's engineering for the sake
of engineering which leads to nothing more than code which is convoluted for
nothing.

So I'd recommend to start small, use the simplest approach possible until you
see clear need to use a more complex one, and then decide what looks/works
best in a particular case. I know, this is a glib piece of advice, but it's
really how the things are ;-)

-- 
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/20221027175042.uhaakvkgnmbvqmh4%40carbon.

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

[Ian Lance Taylor]

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 main go compiler ("gc") as opposed to gollvm. What output do 
> you get when you run "go version" ?

The code is testing whether the compiler supports that option.  The
errors about -fgo-importcfg and -ffile-prefix-map can be ignored.

Not sure what is happening elsewhere, though.  You showed the output
but not the commands.

Ian



> On Thu, Oct 27, 2022 at 12:05 PM 'Qingwei Li' via golang-nuts 
>  wrote:
>>
>> 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() {
>> println("pkgFunc")
>> }
>> ```
>>
>> go.mod
>>
>> ```
>> module easyPkg
>>
>> go 1.18
>> ```
>>
>> use `go build -x . 2> auto.sh` to get the building process. Then delete the 
>> generated binary file `easyPkg` and use `go clean -cache` to clean the 
>> building cache. Then I use the command `source auto.sh` to regenerate the 
>> binary, which fails.
>>
>> part of the error log is as follows
>>
>> ```
>> /data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized command 
>> line option '-fgo-importcfg=/dev/null'
>> /data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized command 
>> line option '-ffile-prefix-map=a=b'
>> ./main.go:3:19: error: 
>> /tmp/go-build3415416681/b001/_importcfgroot_/easyPkg/libPkg.a exists but 
>> does not contain any Go export data
>> ./main.go:3:19: warning: easyPkg/Pkg: Not a directory
>> ./main.go:3:19: error: import file 'easyPkg/Pkg' not found
>> ./main.go:6:2: error: reference to undefined name 'Pkg'
>> /usr/bin/ld.gold: error: /tmp/go-build3415416681/b001/_pkg_.a: member at 72 
>> is not an ELF object
>> /usr/bin/ld.gold: error: /tmp/go-build3415416681/b002/_pkg_.a: member at 72 
>> is not an ELF object
>> buildid: open /tmp/go-build3415416681/b001/exe/a.out: no such file or 
>> directory
>> ```
>>
>> what can I do on the auto.sh script to regenerate the binary file? Is the 
>> process dumped completed?
>>
>> On a single package with no subdirectory, the result of `go build -x .` is 
>> available for regenerating the binary file.
>>
>> Moreover, my main purpose is to add -emit-llvm option wherever `llvm-goc` 
>> appears and use `llvm-link -S` to link all object files generated by 
>> llvm-goc to get a whole LLVM IR file for the whole project. If the question 
>> above is now insoluble, is there any other way to get the whole project's 
>> LLVM IR?
>>
>>
>> --
>> 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/b120de38-d603-4a8d-a029-34351abc051cn%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%2BUr55ENsDS_zpp0TCeyJDfh7jO%2B%3DQOcrfNs1zxqNBYjpPPvDw%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/CAOyqgcUA-Q2kuWFOWXct-GneJ72jYA6_yXH%2BK95KYZwZJtbhfQ%40mail.gmail.com.

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

[Jan Mercl]

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, an ephemeral
@named socket, which nicely handled both the termination condition and the
communication and is even safe for concurrent processes competing with each
other.

On Thu, Oct 27, 2022, 18:05 Vjeran  wrote:

> 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?
>
> --
> 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/6f62afc4-af7a-4548-85c5-6514c2e20a49n%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/CAA40n-W%2BfpjUECDrQhbEEzc%2B-F-Zd6M1h11K5UacwJMHSPaPUw%40mail.gmail.com.

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

['Than McIntosh' via golang-nuts]

>/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 version" ?

Thanks, Than


On Thu, Oct 27, 2022 at 12:05 PM 'Qingwei Li' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> 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() {
> println("pkgFunc")
> }
> ```
>
> go.mod
>
> ```
> module easyPkg
>
> go 1.18
> ```
>
> use `go build -x . 2> auto.sh` to get the building process. Then delete
> the generated binary file `easyPkg` and use `go clean -cache` to clean the
> building cache. Then I use the command `source auto.sh` to regenerate the
> binary, which fails.
>
> part of the error log is as follows
>
> ```
> /data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized
> command line option '-fgo-importcfg=/dev/null'
> /data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized
> command line option '-ffile-prefix-map=a=b'
> ./main.go:3:19: error:
> /tmp/go-build3415416681/b001/_importcfgroot_/easyPkg/libPkg.a exists but
> does not contain any Go export data
> ./main.go:3:19: warning: easyPkg/Pkg: Not a directory
> ./main.go:3:19: error: import file 'easyPkg/Pkg' not found
> ./main.go:6:2: error: reference to undefined name 'Pkg'
> /usr/bin/ld.gold: error: /tmp/go-build3415416681/b001/_pkg_.a: member at
> 72 is not an ELF object
> /usr/bin/ld.gold: error: /tmp/go-build3415416681/b002/_pkg_.a: member at
> 72 is not an ELF object
> buildid: open /tmp/go-build3415416681/b001/exe/a.out: no such file or
> directory
> ```
>
> what can I do on the auto.sh script to regenerate the binary file? Is the
> process dumped completed?
>
> On a single package with no subdirectory, the result of `go build -x .` is
> available for regenerating the binary file.
>
> Moreover, my main purpose is to add -emit-llvm option wherever `llvm-goc`
> appears and use `llvm-link -S` to link all object files generated by
> llvm-goc to get a whole LLVM IR file for the whole project. If the question
> above is now insoluble, is there any other way to get the whole project's
> LLVM IR?
>
>
> --
> 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/b120de38-d603-4a8d-a029-34351abc051cn%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%2BUr55ENsDS_zpp0TCeyJDfh7jO%2B%3DQOcrfNs1zxqNBYjpPPvDw%40mail.gmail.com.

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

[Vjeran]

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?

-- 
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/6f62afc4-af7a-4548-85c5-6514c2e20a49n%40googlegroups.com.

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

['Qingwei Li' via golang-nuts]

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() {
println("pkgFunc")
}
```

go.mod

```
module easyPkg

go 1.18
```

use `go build -x . 2> auto.sh` to get the building process. Then delete the 
generated binary file `easyPkg` and use `go clean -cache` to clean the 
building cache. Then I use the command `source auto.sh` to regenerate the 
binary, which fails.

part of the error log is as follows

```
/data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized 
command line option '-fgo-importcfg=/dev/null'
/data/mygo/gollvm_workarea/install/bin/llvm-goc: error: unrecognized 
command line option '-ffile-prefix-map=a=b'
./main.go:3:19: error: 
/tmp/go-build3415416681/b001/_importcfgroot_/easyPkg/libPkg.a exists but 
does not contain any Go export data
./main.go:3:19: warning: easyPkg/Pkg: Not a directory
./main.go:3:19: error: import file 'easyPkg/Pkg' not found
./main.go:6:2: error: reference to undefined name 'Pkg'
/usr/bin/ld.gold: error: /tmp/go-build3415416681/b001/_pkg_.a: member at 72 
is not an ELF object
/usr/bin/ld.gold: error: /tmp/go-build3415416681/b002/_pkg_.a: member at 72 
is not an ELF object
buildid: open /tmp/go-build3415416681/b001/exe/a.out: no such file or 
directory
```

what can I do on the auto.sh script to regenerate the binary file? Is the 
process dumped completed?

On a single package with no subdirectory, the result of `go build -x .` is 
available for regenerating the binary file.

Moreover, my main purpose is to add -emit-llvm option wherever `llvm-goc` 
appears and use `llvm-link -S` to link all object files generated by 
llvm-goc to get a whole LLVM IR file for the whole project. If the question 
above is now insoluble, is there any other way to get the whole project's 
LLVM IR?


-- 
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/b120de38-d603-4a8d-a029-34351abc051cn%40googlegroups.com.

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

[Gergely Brautigam]

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 {
err = tmpErr
}
 }()

 err = doSomethingElse()
 return err
}

Or:
func test() (errList []error) {
defer func() {
if tmpErr := doSomething(); tmpErr != nil {
errList = append(errList, tmpErr)
}
 }()

 if err := doSomethingElse(); err != nil {
  errList = append(errList, err)
 }
 return errList
}

Or even something else entirely? 

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/edba9f2b-7a06-445b-8a8f-1e52f8f1b847n%40googlegroups.com.

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

[Marvin Renich]

* 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 language.

First, every single programmer who has used any other C-like language
knows %y %m %d %H %M %S.  For English speakers (native or as a second
language), these have mnemonic associations with the values they
represent.  When writing a strftime format, there is no reason to look
at the man page for common usage.

For Go's Time.Format, it is almost always necessary to refer to the
documentation to get the correct numbers, or to at least think
"month/day hour:minute:second" and then apply numbers to them.  When
formatting a date, I almost always want a year; where is that in the
order?  Before month (where it should be)?  No!  Between day and hour as
in typical US formatting?  Sorry, wrong again.  This is significantly
more cognitive load than using the mnemonics.

And this is just writing code; the cognitive load is even worse when
reading someone else's code, especially when doing a code review and
trying to make sure the other programmer did it correctly.

Second, Go's fmt.Printf uses % escapes for substitutions, but it uses a
completely different syntax for time formatting substitutions.
Really???  For a language that tries to be as simple and consistent as
possible, this doesn't make any sense, especially when there is already
a well-known %-escape model to start with.

Third, and worst of all, there is no way to escape literal digits in the
format string.  How do you write the Go equivalent of C's "%A, 4 minutes
after %H:%M"?  You either have to call Format twice and combine three
strings, or you have to do string substitution after calling Format.

The picture-style format string is a "cool" idea, but impractical for
real programming and a serious design flaw.  I have always wished that I
were able to convince the Go devs to add a new Time.FormatDoneRight that
used %-style formatting.  I would not copy C's "lots of letters for
different styles of the same value"; I would use modifiers like "%0m"
for two-digit month.  And I would give day-of-year its own letter (why
does day-of-year use the same number as day-of-month?)

...Marvin

-- 
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/Y1qAZwYwTlgXYIRp%40basil.wdw.

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

['Michel Levieux' via golang-nuts]

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 tagged back from 
> https://go.dev/blog/path-security, and we've started tagging some other 
> golang.org/x repositories now. They'll be tagged every month or so if 
> they have changes, and their dependencies on each other will be upgraded.
>
> Note that so far these are all v0 versions, so they're not necessarily 
> stable as you said in your subject. No stability promises have changed as a 
> result of these tags. That said, now that we have a process for automatic 
> tagging, some repositories may be more likely to tag to a stable version. 
> See https://go.dev/issue/56325.
>
> I didn't think this change warranted an announcement, but I'll discuss it 
> and maybe reconsider. Thanks.
>
> On Wednesday, October 26, 2022 at 2:21:37 PM UTC-4 michel@doctolib.com 
> wrote:
>
>> Hi all,
>>
>> I was bumping the dependencies of our codebase today, and noticed that 
>> many packages under golang.org/x/ had upgraded from a pseudo-version to 
>> a real, semver version:
>>
>> -   golang.org/x/net 
>>  
>> v0.0.0-20220927171203-f486391704dc // indirect 
>> -golang.org/x/sync 
>>  
>> v0.0.0-20220923202941-7f9b1623fab7 // indirect 
>> -   golang.org/x/sys 
>>  
>> v0.0.0-20220928140112-f11e5e49a4ec // indirect
>> -   golang.org/x/time 
>>  
>> v0.0.0-2022090347-f3bd1da661af // indirect 
>> +   golang.org/x/net  v0.1.0 
>> // indirect 
>> +golang.org/x/sync  v0.1.0 
>> // indirect 
>> +   golang.org/x/sys  v0.1.0 
>> // indirect
>> +   golang.org/x/time  v0.1.0 
>> // indirect
>>
>> ...and others. Is there something we should be aware of concerning this 
>> upgrade? I've seen no announcement everywhere I've been looking, which 
>> makes me suppose there's nothing very interesting going on there but that 
>> surprised me.
>>
>> If anyone has more information, I'll gladly take it! Thanks!
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7065c16c-0769-4b0f-9941-726459aea250n%40googlegroups.com.

Re: [go-nuts] Analyse postgresql error

[David Harel]

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.Error)
> > switch pqerr.Get('C') {
> > case "23505":
> > return "Key violation"
> > }
> > return "Error unknown"
> > }
> >
> > Now I want to be able to test my code thereby generating this type of
> error
> > in the testing function.
> > So I need to create an error variable of the type pq.Error and use it as
> a
> > parameter to db.Mock. Something like:
> >
> > mockDB := wrapper.NewMockQuerier(ctrl)
> > // The part that breaks
> > err := fmt.Errorf("pq: %s", `duplicate key value violates unique
> constraint
> > "treatment_pk"
> > {"Severity":"ERROR","Code":"23505","Message":".MoreStuff."}`)
> >
> > mockDB.EXPECT().AppointmentUpdate(gomock.Any(), gomock.Any()).Return(err)
> >
> > Any idea?
>
> Well, look at what you do:
>
>   fmt.Errorf("pq: %s", `some long text`)
>
> creates a value of some (irrelevant) type implementing the standard
> interface
> error and containing a string which is obtained by calling fmt.Sprintf on
> the
> aguments. The "%s" verb in the format string means "get the string
> representation of the matching argument and insert in into the format
> string
> in place of the verb". Your argument is itself a string, and it is
> completely
> opaque to fmt.Errorf - it's taken "as is" and is not interpreted in any
> way.
>
> Please stop and think of this for a moment: even if the contents of this
> string would be somehow interpreted, how would the code in package fmt
> guess
> it has to produce a value of type pg.Error from that string, and how
> exactly?
>
> So, if you need to create a *pq.Error, go on and do just that in your
> mock. Based on [1], you could do something like
>
>   return {
>   Code: "23505",
>   Severity: "ERROR',
>   Message: `duplicate key value violates unique constraint
> "treatment_pk"`,
>   }
>
>  1.
> https://github.com/lib/pq/blob/d65e6ae4bdd1c86b16cd6d2bcff4fe970dc697b4/error.go#L25
>
>

-- 
דוד הראל
עמוקה
ד.נ. מרום הגליל
1380200
טל: 054-2263892

-- 
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%2BE_%3DOYZ%3DSHOr-VS8nikYR1c17WWF__0BwMx%2B2j6G2ZW8-vfVg%40mail.gmail.com.

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

[Alex Besogonov]

It’s possible to use a different method name (“FormatNew”?) to avoid back 
compat issues. But yeah, it would be a bit ugly.

It might make sense to revisit this if Go ever grows i18n for datetimes.

> On Oct 26, 2022, at 23:44, Rob Pike  wrote:
> 
> Not without breaking compatibility.
> 
> -rob
> 
> 
> On Thu, Oct 27, 2022 at 5:15 PM Alex Besogonov  > wrote:
>> Can we perhaps get a bit more unambiguous reference date for it?
>> 
>> On Wednesday, October 26, 2022 at 1:06:36 PM UTC-7 Rob 'Commander' Pike 
>> wrote:
>>> I believe it's unique. I thought of it one day while walking home. It is 
>>> inspired by the way Cobol picture clauses represent number formats. (That 
>>> said, I've never programmed in Cobol.)
>>> 
>>> -rob
>>> 
>>> 
>>> On Thu, Oct 27, 2022 at 4:51 AM Ayan George > wrote:
 
 I'm really impressed by the simplicity of Go's time formatting and parsing 
 mechanisms -- particularly when compared with strftim().
 
 Does anyone know the origin or history of it?  Is there a precedent for 
 using reference layouts that include string like 2006, January, etc.?
 
 Do other languages provide something similar or is this completely unique 
 to Go?
 
 Can someone point me to or describe the history of Go's time formatting 
 method?
 
 -ayan
 
>>> 
 -- 
 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...@googlegroups.com <>.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/baa45515-cde6-4c7c-a34c-54ddf7da807en%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/c8f3bc05-3b30-45ad-9e7a-4c12481494d8n%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/FD2CADB2-B8FF-4C76-A34F-0C71E2D51402%40gmail.com.

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

[Rob Pike]

Not without breaking compatibility.

-rob


On Thu, Oct 27, 2022 at 5:15 PM Alex Besogonov 
wrote:

> Can we perhaps get a bit more unambiguous reference date for it?
>
> On Wednesday, October 26, 2022 at 1:06:36 PM UTC-7 Rob 'Commander' Pike
> wrote:
>
>> I believe it's unique. I thought of it one day while walking home. It is
>> inspired by the way Cobol picture clauses represent number formats. (That
>> said, I've never programmed in Cobol.)
>>
>> -rob
>>
>>
>> On Thu, Oct 27, 2022 at 4:51 AM Ayan George  wrote:
>>
>>>
>>> I'm really impressed by the simplicity of Go's time formatting and
>>> parsing mechanisms -- particularly when compared with strftim().
>>>
>>> Does anyone know the origin or history of it?  Is there a precedent for
>>> using reference layouts that include string like 2006, January, etc.?
>>>
>>> Do other languages provide something similar or is this completely
>>> unique to Go?
>>>
>>> Can someone point me to or describe the history of Go's time formatting
>>> method?
>>>
>>> -ayan
>>>
>>> --
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/baa45515-cde6-4c7c-a34c-54ddf7da807en%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/c8f3bc05-3b30-45ad-9e7a-4c12481494d8n%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/CAOXNBZT8s3uYCFqFHRN4td%2Bc9GKHN0hQkWNQXFKOZ5zsdYb%2BDQ%40mail.gmail.com.

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

[Alex Besogonov]

Can we perhaps get a bit more unambiguous reference date for it?

On Wednesday, October 26, 2022 at 1:06:36 PM UTC-7 Rob 'Commander' Pike 
wrote:

> I believe it's unique. I thought of it one day while walking home. It is 
> inspired by the way Cobol picture clauses represent number formats. (That 
> said, I've never programmed in Cobol.)
>
> -rob
>
>
> On Thu, Oct 27, 2022 at 4:51 AM Ayan George  wrote:
>
>>
>> I'm really impressed by the simplicity of Go's time formatting and 
>> parsing mechanisms -- particularly when compared with strftim().
>>
>> Does anyone know the origin or history of it?  Is there a precedent for 
>> using reference layouts that include string like 2006, January, etc.?
>>
>> Do other languages provide something similar or is this completely unique 
>> to Go?
>>
>> Can someone point me to or describe the history of Go's time formatting 
>> method?
>>
>> -ayan
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/baa45515-cde6-4c7c-a34c-54ddf7da807en%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/c8f3bc05-3b30-45ad-9e7a-4c12481494d8n%40googlegroups.com.