[go-nuts] Re: golang as ML backend v/s C++

[David Green]

Yeah, You are right.
I has experience of developing backend with Golang.
But it was difficult because it has no bigcommunity.
I want to make a big community of golang backend.

On Sunday, April 14, 2024 at 9:15:51 PM UTC+9 envee wrote:

> After reading briefly about ML and how Python is used as a "veneer" for 
> C++ code, I was wondering why Go is not used as the backend, given it's 
> excellent concurrency support and ease of use.
> Basically, I was thinking if the backend is written as a shared object in 
> Go, and then used in Python using ctypes.
> I have seen a huge number of libraries on the awesome-go website, but 
> don't know if they have Python bindings.
> Any views ?
> What really is a limitation which does not encourage developers to prefer 
> Go over C++ as the ML backend ?
>

-- 
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/f4eabfda-e899-4fcd-bfbf-5564eb14aba3n%40googlegroups.com.

[go-nuts] Using client-go to access a specific context, not current context

[David Karr]

I'm relatively new to golang, although I'm pretty familiar with 
Kubernetes.  I want to see if I can use client-go as a framework for a set 
of scripts that get (or set) information on a specific cluster.  I don't 
want to use the current context, I want to set the context name on the 
command line and "use" that context, but I want to avoid setting that as 
the current context.

I could hack this together by manually navigating through ~/.kube/config 
and extracting the server and token, but I'm still not familiar enough with 
the client-go api to know whether that will even help. In any case, I would 
hope that client-go would provide an easier way to do this.

I wish I could find more examples of "out-of-cluster" client applications 
using this api.

-- 
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/4377e4fd-1d16-431c-8cf2-406d7d2304f3n%40googlegroups.com.

Re: [go-nuts] How to have a raw parameter value in cobra?

[David Karr]

Ok, that worked. I had tried that before, but I had done it wrong.

On Sunday, February 25, 2024 at 1:04:10 PM UTC-8 burak serdar wrote:

> Somewhere in your main, you should be calling rootCmd.Execute(). Instead:
>
> func main() {
> // first, make sure there are at least 2 args. Then, process the
> 1st parameter
> // Then
> rootCmd.SetArgs(os.Args[2:])
> rootCmd.Execute()
> }
>
> On Sun, Feb 25, 2024 at 1:50 PM David Karr  wrote:
> >
> > But where would that be done? I'm not certain of the exact role of the 
> "rootCmd.Execute()" function, or the optional "Run" function in the Command 
> object. Neither of those appear to be executed, when I just run " 
>   subcommand, and that gets printed, but nothing else.
> >
> > On Sunday, February 25, 2024 at 10:52:10 AM UTC-8 burak serdar wrote:
> >>
> >> You can do rootCmd.SetArgs(os.Args[2:]), and process the first
> >> parameter yourself.
> >>
> >> On Sun, Feb 25, 2024 at 11:43 AM David Karr  
> wrote:
> >> >
> >> > I am not a new programmer, but I am pretty new to golang, having only 
> written a couple of small applications, and that was several months ago. 
> I'm trying to construct an application using Cobra, using some nonstandard 
> conventions. Is it better to ask a question like this in an issue in the 
> Cobra github site?
> >> >
> >> > The application I am trying to write will be used extremely often, 
> and I want to minimize the required syntax.
> >> >
> >> > I want to set up a command line like the following:
> >> >
> >> >
> >> >
> >> > The parameter right after the application name will always be 
> present. I don't want it to be a flag. After that parameter value will be a 
> subcommand, followed by additional parameters, also not flags. There are 
> some situations where I want to allow for flags, but that will be uncommon.
> >> >
> >> > It's not clear to me how to cleanly set up this organization. Is it 
> simply not practical to do with Cobra? Should I just do ad hoc parameter 
> processing?
> >> >
> >> > --
> >> > 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/14b9efb1-7fbb-45a6-8e0e-56f25be310a3n%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/9d8fac62-f70a-488d-8bf9-7800b5d44d34n%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/c18c9fe2-c85e-49b9-a3f9-167a8c2236f5n%40googlegroups.com.

Re: [go-nuts] How to have a raw parameter value in cobra?

[David Karr]

But where would that be done?  I'm not certain of the exact role of the 
"rootCmd.Execute()" function, or the optional "Run" function in the Command 
object. Neither of those appear to be executed, when I just run " 
  You can do rootCmd.SetArgs(os.Args[2:]), and process the first
> parameter yourself.
>
> On Sun, Feb 25, 2024 at 11:43 AM David Karr  wrote:
> >
> > I am not a new programmer, but I am pretty new to golang, having only 
> written a couple of small applications, and that was several months ago. 
> I'm trying to construct an application using Cobra, using some nonstandard 
> conventions. Is it better to ask a question like this in an issue in the 
> Cobra github site?
> >
> > The application I am trying to write will be used extremely often, and I 
> want to minimize the required syntax.
> >
> > I want to set up a command line like the following:
> >
> >
> >
> > The parameter right after the application name will always be present. I 
> don't want it to be a flag. After that parameter value will be a 
> subcommand, followed by additional parameters, also not flags. There are 
> some situations where I want to allow for flags, but that will be uncommon.
> >
> > It's not clear to me how to cleanly set up this organization. Is it 
> simply not practical to do with Cobra? Should I just do ad hoc parameter 
> processing?
> >
> > --
> > 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/14b9efb1-7fbb-45a6-8e0e-56f25be310a3n%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/9d8fac62-f70a-488d-8bf9-7800b5d44d34n%40googlegroups.com.

[go-nuts] How to have a raw parameter value in cobra?

[David Karr]

I am not a new programmer, but I am pretty new to golang, having only 
written a couple of small applications, and that was several months ago. 
I'm trying to construct an application using Cobra, using some nonstandard 
conventions. Is it better to ask a question like this in an issue in the 
Cobra github site?

The application I am trying to write will be used extremely often, and I 
want to minimize the required syntax.

I want to set up a command line like the following:

   

The parameter right after the application name will always be present. I 
don't want it to be a flag. After that parameter value will be a 
subcommand, followed by additional parameters, also not flags. There are 
some situations where I want to allow for flags, but that will be uncommon.

It's not clear to me how to cleanly set up this organization.  Is it simply 
not practical to do with Cobra?  Should I just do ad hoc parameter 
processing?

-- 
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/14b9efb1-7fbb-45a6-8e0e-56f25be310a3n%40googlegroups.com.

Re: [go-nuts] Go 1.22 code simplification

[David Finkel]

I don't know of anything that does those rewrites (and haven't looked), but
it looks like gofmt -s could support it by extending this type-switch:
https://cs.opensource.google/go/go/+/master:src/cmd/gofmt/simplify.go;l=16-103;drc=9b89c380208ea2e85985ee6bf2b1d684274dfa1d

I like the idea of an automatic rewrite of those loop primitives, though.

(it's possible that the x := x case may need type/declaration-location
information that gofmt doesn't have to do robustly, though)

Note: the go fix directory hasn't had any commits since August, so it
doesn't appear to have it either. (that might be the right place for that
rewrite -- although, I think vet also has a suggested fix capacity that
would make sense for any module with the go line set to 1.22+)

On Tue, Jan 16, 2024 at 1:33 AM Amnon  wrote:

> Go 1.22 contains some cool features which will allow us to write simpler
> code.
>
> Would it be possible for gofmt -s to help us do transformations which
> clean up old code such as
> for i := 0; i < n; i++   -> for i := range n
> removing x := x assignments inside range loops
> or updating code to use the new math/rand/v2 API?
>
> If not, has anyone written any refactoring tools to do this?
>
>
> --
> 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/91a531a9-5043-4357-b643-d1600dcae119n%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/CANrC0BjVSPpqKF%3DUWppq3zS_NNjKvjsjKj6UmaaMy%2BCnrR7q4A%40mail.gmail.com.

[go-nuts] Re: Go 1.22 Release Candidate 1 is released

[John David Lee]

This is in the section titled "Why are yield functions limited to at most 
two arguments?"

On Sunday, December 24, 2023 at 5:43:23 PM UTC+1 John David Lee wrote:

> Hello.
>
> In the rangefunc experiment document 
> <https://go.dev/wiki/RangefuncExperiment> the iter package is said to 
> export the following:
>
> type Seq[V any] func(yield func(V) bool) bool 
> type Seq2[K, V any] func(yield func(K, V) bool) bool
>
> But after installing tip, it looks like the iter package exposes a 
> slightly different interface: 
>
> type Seq[V any] func(yield func(V) bool)
> type Seq2[K, V any] func(yield func(K, V) bool)
>
> Take care,
>
> David
> On Wednesday, December 20, 2023 at 12:43:36 AM UTC+1 anno...@golang.org 
> wrote:
>
>> Hello gophers,
>>
>> We have just released go1.22rc1, a release candidate version of Go 1.22.
>> It is cut from release-branch.go1.22 at the revision tagged go1.22rc1.
>>
>> Please try your production load tests and unit tests with the new version.
>> Your help testing these pre-release versions is invaluable.
>>
>> Report any problems using the issue tracker:
>> https://go.dev/issue/new
>>
>> If you have Go installed already, an easy way to try go1.22rc1
>> is by using the go command:
>> $ go install golang.org/dl/go1.22rc1@latest
>> $ go1.22rc1 download
>>
>> You can download binary and source distributions from the usual place:
>> https://go.dev/dl/#go1.22rc1
>>
>> To find out what has changed in Go 1.22, read the draft release notes:
>> https://tip.golang.org/doc/go1.22
>>
>> Cheers,
>> Than and Carlos for the Go team
>>
>

-- 
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/fe33a8dc-fbca-48a0-9320-ef383aec7a9en%40googlegroups.com.

[go-nuts] Re: Go 1.22 Release Candidate 1 is released

[John David Lee]

Hello.

In the rangefunc experiment document 
<https://go.dev/wiki/RangefuncExperiment> the iter package is said to 
export the following:

type Seq[V any] func(yield func(V) bool) bool 
type Seq2[K, V any] func(yield func(K, V) bool) bool

But after installing tip, it looks like the iter package exposes a slightly 
different interface: 

type Seq[V any] func(yield func(V) bool)
type Seq2[K, V any] func(yield func(K, V) bool)

Take care,

David
On Wednesday, December 20, 2023 at 12:43:36 AM UTC+1 anno...@golang.org 
wrote:

> Hello gophers,
>
> We have just released go1.22rc1, a release candidate version of Go 1.22.
> It is cut from release-branch.go1.22 at the revision tagged go1.22rc1.
>
> Please try your production load tests and unit tests with the new version.
> Your help testing these pre-release versions is invaluable.
>
> Report any problems using the issue tracker:
> https://go.dev/issue/new
>
> If you have Go installed already, an easy way to try go1.22rc1
> is by using the go command:
> $ go install golang.org/dl/go1.22rc1@latest
> $ go1.22rc1 download
>
> You can download binary and source distributions from the usual place:
> https://go.dev/dl/#go1.22rc1
>
> To find out what has changed in Go 1.22, read the draft release notes:
> https://tip.golang.org/doc/go1.22
>
> Cheers,
> Than and Carlos for the Go team
>

-- 
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/014d606e-3f5c-44fa-8c92-b6ef41b21941n%40googlegroups.com.

Re: [go-nuts] Generic assembly function

[David Finkel]

On Thu, Dec 14, 2023 at 10:43 PM Clément Jean 
wrote:

> Hi,
>
> I'm currently learning how to write Go assembly on arm64 and I made the
> following functions:
>
> TEXT ·AddVector16(SB),NOSPLIT,$0-48
> MOVD a+0(FP), R0
> MOVD a+8(FP), R1
> MOVD a+16(FP), R2
> MOVD a+24(FP), R3
> VMOV R0, V0.D[0]
> VMOV R1, V0.D[1]
> VMOV R2, V1.D[0]
> VMOV R3, V1.D[1]
> VADD V1.B16, V0.B16, V0.B16
> VMOV V0.D[0], R0
> VMOV V0.D[1], R1
> MOVD R0, ret+32(FP)
> MOVD R1, ret+40(FP)
> RET
>
> TEXT ·AddVector32(SB),NOSPLIT,$0-96
> MOVD a+0(FP), R0
> MOVD a+8(FP), R1
> MOVD a+16(FP), R2
> MOVD a+24(FP), R3
> MOVD a+32(FP), R4
> MOVD a+40(FP), R5
> MOVD a+48(FP), R6
> MOVD a+56(FP), R7
> VMOV R0, V0.D[0]
> VMOV R1, V0.D[1]
> VMOV R2, V1.D[0]
> VMOV R3, V1.D[1]
> VMOV R4, V2.D[0]
> VMOV R5, V2.D[1]
> VMOV R6, V3.D[0]
> VMOV R7, V3.D[1]
> VADD V2.B16, V0.B16, V0.B16
> VADD V3.B16, V1.B16, V1.B16
> VMOV V0.D[0], R0
> VMOV V0.D[1], R1
> VMOV V1.D[0], R2
> VMOV V1.D[1], R3
> MOVD R0, ret+64(FP)
> MOVD R1, ret+72(FP)
> MOVD R2, ret+80(FP)
> MOVD R3, ret+88(FP)
> RET
> While these work, I'm forced to add the 16 and 32 suffixes. Is there any
> way to have only one function name and link the assembly to something like:
> type Uint8x16 [16]uint8
> type Uint8x32 [32]uint8
>
> //go:noescape
> func AddVector[T Uint8x16 | Uint8x32](a, b T) T
> If there is let me know, otherwise is there some other alternatives?
>
>
Unfortunately, I think a suffix is the best you can do without jumping
through some serious (and ugly) hoops.
The generics implementation opted for a "stenciling" approach, (and doesn't
support specializations) so although the symbols do encode the GC shape a
bit.
Here's the design doc for GC Shape Stenciling
https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md



> Btw any feedback on the assembly is welcome, I'm new to 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/3224bd47-2747-4e1d-bbc5-4a5c4a300f85n%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/CANrC0Bh8ZB2R87pEJJ8eKA%3DZiSRjGpa%2BawjX8vdc0dfCMExuBQ%40mail.gmail.com.

Re: [go-nuts] I need confirmation about whether I'm in front of a linter false positive.

[David Finkel]

On Mon, Aug 14, 2023 at 4:54 PM Pablo Caballero  wrote:

> I started working on a Golang project (from my work). The following
> pattern makes the company configured linter to complain with:
> sloppyReassign: re-assignment to `err` can be replaced with `err :=
> myFunc2()` (gocritic)
>
> func myFunc() error {
> ...
> blah, err := getBlah()
> if err != nil {
> return err
> }
> ...
> if err = myFunc2; err != nil {
> return err
> }
> ...
> }
>
> What bothers me the most is the fact that if I listen to the linter and
> change the code according to its suggestion I get another complaint saying
> that I should use the if short version.
>
> Yes, I have found silenced sloppyReassign following this pattern.
>
> What do you think? What linter complaint should I mute? I don't like the
> idea of a code base polluted with instructions to tell the linter to shut
> up. Do you think I should suggest stopping using linters? :)
>
My recommendation is to stop re-using the "err" variable.
I eliminated missed if err != nil checks in my codebases by using unique
names for my error-typed variables. (and reserving the "err" itself for
innermost scopes -- short if statements like the second case you have there)


>
> Thank you!
>
> --
> 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/CAPxFe-utkjMEVrc3DtTR5rmsiEuK8ZLvA6d228PjnroaxRtBkw%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/CANrC0Bj5Q6N6otD0QS1i3JFqB9EzPNwYbmTrDOW6PRGxX0Fr8g%40mail.gmail.com.

Re: [go-nuts] no way to pause `Listen` on net connections

[David N]

Yup, this makes sense and should work, but I'm still surprised this can't
be entirely done in Golang.

On Mon, Jul 24, 2023 at 10:49 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Mon, Jul 24, 2023 at 9:14 AM David N  wrote:
>
> On Linux you may try fiddling with iptables, limitations apply:
>
> https://stackoverflow.com/questions/44464617/stop-accepting-new-tcp-connections-without-dropping-any-existing-ones/44509993#44509993
>

-- 
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/CAN7%3DS7hkBBe%3Dg4a2Dva0srYxuXAPhkfWFXDCHLv%2BqQhHXX4iWw%40mail.gmail.com.

Re: [go-nuts] no way to pause `Listen` on net connections

[David N]

I've posted a snippet in the so question:

```go

l, err := net.Listen("tcp", ":2000")if err != nil {
  log.Fatal(err)
}
for {
conn, err := l.Accept() // BLOCKING HERE
...
}
```

iiuc, your solution only checks on the start as eventually you have to
call `l.Accept()` and be blocked again.

you can modify the above code in any way where it'd receive a signal
(e.g. Ctrl+C) and breaks out of either `l.Accept` or stops
`net.listen`, either works.



On Mon, Jul 24, 2023 at 9:39 AM Bakul Shah  wrote:

> You can do a non-blocking select on a channel prior to l.Accept(). If
> there is a pause message, you do a blocking select on the same channel for
> an resume or finish message. A separate goroutine can send you those
> messages depending on conditions under which you want to pause or resume.
>
> If the above doesn't make sense write a sample program on play.golang.org,
> which does roughly want you want except for pause/resume, and post a link
> here and we can modify it for pause/resume.
>
> On Jul 21, 2023, at 10:47 PM, David N  wrote:
>
> I've posted this question on stackoverflow
> <https://stackoverflow.com/questions/76447195/how-to-suspend-and-resume-accepting-new-connections-in-net-listener>,
> discussed it with some members of the golang community, and I was
> encouraged to post here.
>
> Problem: I have a secure application and I want to pause/resume accepting
> network connections, calling `l.Accept()` blocks the thread, thus you can't
> pause in a single-thread program. You can use goroutines but that still
> isn't ideal, as the routine would still accept the connection first and
> only then can close it if you're in "pause" mode.
>
> This could be solved by:
> - having a non-blocking, async, `l.Accept()`
> - returning a handle to (accepting) goroutine and killing/re-creating it
> from main thread
> - accepting connections in a separate process and communicating over a
> socket
>
> The 1st one doesn't exist, the 2nd one is not accepted by the language
> designers, and the 3rd one is unnecessarily complex and prone to break.
>
> This looks like a shortcoming of golang, is it worth discussing further
> with lang designers?
>
> --
> 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/CAN7%3DS7htWfYUQmd3H8GiWoWSaei1qU-FMcpqdyccFkXN1kmsWg%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAN7%3DS7htWfYUQmd3H8GiWoWSaei1qU-FMcpqdyccFkXN1kmsWg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
>

-- 
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/CAN7%3DS7jaB3b49oxyz9d4otsqGqDuQdcnigd9qvV0%3DasX172-AA%40mail.gmail.com.

Re: [go-nuts] no way to pause `Listen` on net connections

[David N]

I see, so let's take a step back, I want to pause/resume `net.Listen()`.
Unlike a web server, my application doesn't need to always be on, in fact
it only comes online once the user decides, responds to the requests, and
would sleep again until needed - when given signal again by the user (and
not the network).

Thus, I need to be able to show that no packet is transmitted in the
hibernate stage, as it could *potentially* leak sensitive data. The flag
approach makes sense, but it's not 100% secure, as the machine would still
be sending SYN & ACK packets.

Does that make sense?

On Mon, Jul 24, 2023 at 9:10 AM Kurtis Rader  wrote:

> I think we are going to need more context. If you were able to pause
> net.Listen().Accept() the kernel's listen queue would eventually fill and
> the kernel would reject any new connection requests. And when you resumed
> accepting connections if enough time had elapsed those old connection
> requests would no longer be valid. I don't see why you need any of the
> three solutions you proposed. Why not simply set a flag that indicates
> whether new connections should be handled? If the flag is false simply
> accept the connection request then close the connection (or do whatever
> else makes sense). I read your StackOverflow question and am still
> perplexed what problem you are trying to solve.
>
> On Sun, Jul 23, 2023 at 10:11 PM David N  wrote:
>
>> I've posted this question on stackoverflow
>> <https://stackoverflow.com/questions/76447195/how-to-suspend-and-resume-accepting-new-connections-in-net-listener>,
>> discussed it with some members of the golang community, and I was
>> encouraged to post here.
>>
>> Problem: I have a secure application and I want to pause/resume accepting
>> network connections, calling `l.Accept()` blocks the thread, thus you can't
>> pause in a single-thread program. You can use goroutines but that still
>> isn't ideal, as the routine would still accept the connection first and
>> only then can close it if you're in "pause" mode.
>>
>> This could be solved by:
>> - having a non-blocking, async, `l.Accept()`
>> - returning a handle to (accepting) goroutine and killing/re-creating it
>> from main thread
>> - accepting connections in a separate process and communicating over a
>> socket
>>
>> The 1st one doesn't exist, the 2nd one is not accepted by the language
>> designers, and the 3rd one is unnecessarily complex and prone to break.
>>
>> This looks like a shortcoming of golang, is it worth discussing further
>> with lang designers?
>>
>> --
>> 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/CAN7%3DS7htWfYUQmd3H8GiWoWSaei1qU-FMcpqdyccFkXN1kmsWg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAN7%3DS7htWfYUQmd3H8GiWoWSaei1qU-FMcpqdyccFkXN1kmsWg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> 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/CAN7%3DS7iG9by0GmXC-HZeRhHPn5quEbr8%3Dk54OmrYodi2%2BY5EoA%40mail.gmail.com.

[go-nuts] no way to pause `Listen` on net connections

[David N]

I've posted this question on stackoverflow
,
discussed it with some members of the golang community, and I was
encouraged to post here.

Problem: I have a secure application and I want to pause/resume accepting
network connections, calling `l.Accept()` blocks the thread, thus you can't
pause in a single-thread program. You can use goroutines but that still
isn't ideal, as the routine would still accept the connection first and
only then can close it if you're in "pause" mode.

This could be solved by:
- having a non-blocking, async, `l.Accept()`
- returning a handle to (accepting) goroutine and killing/re-creating it
from main thread
- accepting connections in a separate process and communicating over a
socket

The 1st one doesn't exist, the 2nd one is not accepted by the language
designers, and the 3rd one is unnecessarily complex and prone to break.

This looks like a shortcoming of golang, is it worth discussing further
with lang designers?

-- 
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/CAN7%3DS7htWfYUQmd3H8GiWoWSaei1qU-FMcpqdyccFkXN1kmsWg%40mail.gmail.com.

[go-nuts] building go 1.20.1 to C for use in Nodejs

[David Choi (jsoneaday)]

Hi I'm trying to build my project as C so I can call it from Nodejs. But 
when I run the command "go build -buildmode=c-shared -o keyring.so ." I get 
a so file but no h C header.

I am running this on Mac M1. I read something about cgo being disabled by 
default on mac's without the c toolchain but I do have gcc installed so not 
sure what's up.

-- 
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/f043923d-1d16-43ae-9376-925dc39ab4b5n%40googlegroups.com.

Re: [go-nuts] Why is runtime.Gosched needed in this single-threaded, no-goroutines cgo program?

[David Finkel]

On Wed, Feb 15, 2023 at 4:05 PM Ian Lance Taylor  wrote:

> On Wed, Feb 15, 2023 at 8:42 AM 'Marko Bencun' via golang-nuts
>  wrote:
> >
> > I am running into a a weird error in C code that only materializes
> > when calling it from Go using cgo. I hope you could help me understand
> > this behaviour and why calling runtime.Gosched() seems to resolve the
> > issue. I worry that this may not be the right fix, so I want to
> > understand what is going on.
> >
> > I communicate to a USB HID device and get an error every once in a
> > while, only when using cgo, in around 5% of the messages sent to the
> > device, non-deterministically. The messages sent and received are all
> > the same and work most of the time.
> >
> > The C functions I am calling are hid_write and hid_read from here:
> >
> https://github.com/libusb/hidapi/blob/4ebce6b5059b086d05ca7e091ce04a5fd08ac3ac/mac/hid.c
> >
> > If I call hid_write and hid_read in a loop in a C program, everything
> > works as expected:
> >
> > ```
> > #include "hidapi.h"
> > #include "hidapi_darwin.h"
> >
> > int run(hid_device *handle) {
> > int res;
> >
> > const uint8_t write[64] = "";
> > const uint8_t expected[64] = "";
> > uint8_t read[64] = {0};
> >
> > while(1) {
> > res = hid_write(handle, write, sizeof(write));
> > if(res < 0) return -1;
> > res = hid_read(handle, read, sizeof(read));
> > if(res < 0) return -1;
> > if (memcmp(read, expected, 64)) return -1;
> > }
> >
> > return 0;
> > }
> > ```
> >
> > I ported the above to Go using cgo like below. I link `hid.o`, the
> > same object file used in the C program, to make sure the same code is
> > running to rule out differences in compilation:
> >
> > ```
> > package main
> >
> > import (
> > "bytes"
> > "encoding/hex"
> > )
> >
> > /*
> > #cgo darwin LDFLAGS: -framework IOKit -framework CoreFoundation
> > -framework AppKit hid.o
> > #include "hidapi.h"
> > #include "hidapi_darwin.h"
> > */
> > import "C"
> >
> > func main() {
> > dev := C.hid_open(...)
> > if dev == nil {
> > panic("no device")
> > }
> > write := []byte("")
> > expected := []byte("")
> > b := make([]byte, 64)
> > for {
> > written := C.hid_write(dev, (*C.uchar)([0]),
> C.size_t(len(write)))
> > if written < 0 {
> > panic("error write")
> > }
> > read := C.hid_read(dev, (*C.uchar)([0]), C.size_t(len(b)))
> > if read < 0 {
> > panic("error read")
> > }
> > if !bytes.Equal(b, expected) {
> > panic("not equal")
> > }
> > }
> > }
> > ```
> >
> > The Go program errors on hid_write with a "generic error" error code
> > non-deterministically in about 5% of the messages sent. The USB device
> > receives the message and responds normally however.
> >
> > I randomly tried adding `runtime.Gosched()` at the bottom of the
> > Go-loop, and the issue disappeared completely. I am very confused why
> > that would help, as the Go program has, as far as I can tell, no
> > threads and no goroutines (except main).
> >
> > Other things I have checked:
> >
> > - If I move the loop from Go to C by calling `C.run(dev)` (the looping
> > function defined above) from Go, there is no issue.
> > - LockOSThread: if the loop runs in a goroutine and that goroutine
> > switches OS threads, the issue reappears after some time (not
> > immediately after a thread switch - the error happens
> > non-deterministically) even if `runtime.Gosched()` is called.
> > `runtime.LockOSThread()` is needed to fix it in that case. Since the
> > goroutine is locked to an OS thread during the execution of a C
> > function call anyway, this indicates that either hidapi or the macOS
> > HID functions rely on thread-local vars across multiple C calls in
> > some way, which seems a bit crazy.
> > - In the above code (no goroutines), I checked that the OS thread ID
> > (pthread_self()) is constant for all calls, and yet the issue appears
> > unless runtime.Gosched() is called, which seems to contradict the
> > previous point
> > - I tried multiple Go versions between 1.16 and 1.20 and multiple
> > macOS SDK versions between 10.13 and 13.1, all with the same problem
> > (and same working fix).
> > - only macOS is affected - on linux and Windows, there is no similar
> > issue (these platforms use different C code to interact with the
> > device).
> >
> > Does anyone have any insight into why invoking the scheduler could be
> > necessary here or what could be going on in general? My worry is that
> > using `runtime.LockOSThread()` and `runtime.Gosched()` are not proper
> > fixes.
>
>
> I didn't try to look at this in detail, but I did glance at the C code
> you are calling, and it uses pthread_mutex_lock and friends.  In
> general pthread mutexes must be unlocked by the thread that locked
> them, so it is quite possible that LockOSThread is required for
> correct operation.  I don't have an 

Re: [go-nuts] Why can't a regexp.Regexp be const

[David Finkel]

On Mon, Feb 13, 2023 at 6:48 PM Pat Farrell  wrote:

> This won't compile
>
> var ExtRegex =
> regexp.MustCompile("(M|m)(p|P)(3|4))|((F|f)(L|l)(A|a)(C|c))$")
>
> with a
> ./prog.go:10:18:
> regexp.MustCompile("((M|m)(p|P)(3|4))|((F|f)(L|l)(A|a)(C|c))$") (value of
> type *regexp.Regexp) is not constant
>
That error indicates that you wrote `const ExtRegex = `

>
> while
> const pat = "((M|m)(p|P)(3|4))|((F|f)(L|l)(A|a)(C|c))$"
> var ExtRegex = regexp.MustCompile(pat)
>
> Works fine.
> So, why can't the regexp be a constant?
>
 Only primitive types are allowed to be constant in go


> Is there some state that is kept in the regexp.Regexp store?
>
It used to, but that was removed in an earlier version (see the deprecation
notice on regexp.Copy )

>
> And perhaps more importantly, what is the proper go style to
> have a compiled regexp?
> I could put the var statement outside all blocks, so its in effect
> a package variable. But I think having package variable is bad form.
>
For cases like this, I tend to create an unexported package variable that's
initialized with MustCompile.
package-level variables are generally bad-form, but there are cases where
you have mostly-readonly things that must be initialized at startup in
which they make sense. (constant-initialized regexps are one of these)

>
> I'm using the regexp in a loop for all the strings in all the files in a
> directory tree.
> I really don't want to compile them for ever pass thru the lines
>
> Thanks
> Pat
>
> --
> 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/39ae6e9f-1c27-45cd-93c2-39a3b75cc6a3n%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/CANrC0Bj8UUaNeq0pKrx_xUrDkndaS13e4LBPnp5TdAZctBsG3Q%40mail.gmail.com.

[go-nuts] Re: CBOR / pq cryptography migration / software architecture golang question

[David Stainton]

Upon further reflection I think the simplest solution is to have 
MixDescriptor represent the maps of mix keys in raw bytes and use a method 
to unmarshal them when needed.
The unmarshal method could use CBOR tags to figure out which type to 
unmarshal into but it would be easier to implement this where a Sphinx 
Geometry object is an argument to the method which does the unmarshaling; 
and using that Sphinx Geometry to determine which concrete cryptographic 
key type should be used.

On Friday, February 10, 2023 at 6:19:55 PM UTC-5 David Stainton wrote:

>
> Greetings people of golang, cryptographers, software architects,
>
> Hi. I'm a Katzenpost developer, it's a software project, not a legal 
> entity: https://github.com/katzenpost
>
> We use the golang CBOR library: github.com/fxamacker/cbor
> Works great!
>
> Jumping right into the nitty gritty here... We have a "directory 
> authority" protocol (similar to Tor's directory authority protocol) which 
> votes and publishes a "network view" document which contains many 
> MixDescriptor objects, one for each network node (known as a mix).
> Each mix published several mix keys for future Epochs in their 
> MixDescriptor. So we have a map of these mix keys, like so:
>
>
> https://github.com/katzenpost/katzenpost/blob/main/core/pki/descriptor.go#L65
>
> However, currently the map of keys only stores X25519 keys. But ideally 
> we'd like the MixDescriptor struct to be more accommodating to migrating to 
> hybrid post quantum keys.
>
> How might we accomplish this?
> Acceptable solutions will not create intermediary types to represent the 
> entire MixDescriptor... but there should be no objections to intermediary 
> types for representing a single field of the MixDescriptor; like a wrapper 
> type for the map of mix keys?
>
> Also... can I just point out now that two of the MixDescriptor fields are 
> interface types representing two different kinds of cryptographic public 
> key, yet we manage to CBOR unmarshal everything just fine without an 
> intermediary type, with this trick here:
>
>
> https://github.com/katzenpost/katzenpost/blob/main/core/pki/descriptor.go#L123-L127
>
> So we initialize those two fields with valid empty types that implement 
> those interfaces. Fine. But that won't work for a map of interface types, 
> right?
>
> Let's come back to this question soon, and now take a brief digression to 
> discuss katzenpost architecture design:
>
> These mix keys are used by a nested encrypted packet format known as 
> Sphinx (here's the paper 
> https://www.cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf ). Long story 
> short, our Sphinx can use any NIKE (non-interactive key exchange e.g. 
> X25519) and any KEM (key encapsulation mechanism):
>
> code: https://github.com/katzenpost/katzenpost/tree/main/core/sphinx
> design spec: 
> https://github.com/katzenpost/katzenpost/blob/main/docs/specs/sphinx.rst
> design amendment for KEM: 
> https://github.com/katzenpost/katzenpost/blob/main/docs/specs/kemsphinx.rst
>
> Backing up a bit, our "directory authority" publishes a document of this 
> type:
> https://github.com/katzenpost/katzenpost/blob/main/core/pki/document.go#L77
>
> which contains many MixDescriptor objects for the entire network:
>
> https://github.com/katzenpost/katzenpost/blob/main/core/pki/document.go#L128
>
> Currently all network components use Sphinx with a geometry that is 
> hardcoded. However I've got a work-in-progress branch where I'm changing 
> things to distribute the Sphinx geometry in the directory authority 
> document:
>
>
> https://github.com/katzenpost/katzenpost/blob/sphinx_geo_pki/core/sphinx/geo/geo.go#L31-L89
>
>
> https://github.com/katzenpost/katzenpost/blob/sphinx_geo_pki/core/pki/document.go#L152
>
> The Sphinx Geometry describes it's KEM or NIKE:
>
> https://github.com/katzenpost/katzenpost/blob/sphinx_geo_pki/core/sphinx/geo/geo.go#L82-L88
>
> So I guess my question is: How shall I marshal/unmarshal a map of public 
> keys where the keys themselves can be any type that satisfies our NIKE 
> interface or KEM inteface?
>
> It would be silly to put a bunch of concrete key maps into MixDescriptor. 
> There will always be more KEMs and NIKEs.
>
> It sounds like I need change the MixKeys field of the MixDescriptor to use 
> a wrapper type instead of a map directly. The wrapper type would have it's 
> own UnmarshalBinary/MarshalBinary (so that cbor.Marshal/Unmarshal can be 
> called) which would represent the map as a list of two tuples: key, value. 
> Easy to convert it to a map.
>
> What do you think of this approach?
>
> type KeyValue struct {
> Key uint64
> Value mixkey.Public

[go-nuts] CBOR / pq cryptography migration / software architecture golang question

[David Stainton]

Greetings people of golang, cryptographers, software architects,

Hi. I'm a Katzenpost developer, it's a software project, not a legal 
entity: https://github.com/katzenpost

We use the golang CBOR library: github.com/fxamacker/cbor
Works great!

Jumping right into the nitty gritty here... We have a "directory authority" 
protocol (similar to Tor's directory authority protocol) which votes and 
publishes a "network view" document which contains many MixDescriptor 
objects, one for each network node (known as a mix).
Each mix published several mix keys for future Epochs in their 
MixDescriptor. So we have a map of these mix keys, like so:

https://github.com/katzenpost/katzenpost/blob/main/core/pki/descriptor.go#L65

However, currently the map of keys only stores X25519 keys. But ideally 
we'd like the MixDescriptor struct to be more accommodating to migrating to 
hybrid post quantum keys.

How might we accomplish this?
Acceptable solutions will not create intermediary types to represent the 
entire MixDescriptor... but there should be no objections to intermediary 
types for representing a single field of the MixDescriptor; like a wrapper 
type for the map of mix keys?

Also... can I just point out now that two of the MixDescriptor fields are 
interface types representing two different kinds of cryptographic public 
key, yet we manage to CBOR unmarshal everything just fine without an 
intermediary type, with this trick here:

https://github.com/katzenpost/katzenpost/blob/main/core/pki/descriptor.go#L123-L127

So we initialize those two fields with valid empty types that implement 
those interfaces. Fine. But that won't work for a map of interface types, 
right?

Let's come back to this question soon, and now take a brief digression to 
discuss katzenpost architecture design:

These mix keys are used by a nested encrypted packet format known as Sphinx 
(here's the paper 
https://www.cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf ). Long story 
short, our Sphinx can use any NIKE (non-interactive key exchange e.g. 
X25519) and any KEM (key encapsulation mechanism):

code: https://github.com/katzenpost/katzenpost/tree/main/core/sphinx
design spec: 
https://github.com/katzenpost/katzenpost/blob/main/docs/specs/sphinx.rst
design amendment for KEM: 
https://github.com/katzenpost/katzenpost/blob/main/docs/specs/kemsphinx.rst

Backing up a bit, our "directory authority" publishes a document of this 
type:
https://github.com/katzenpost/katzenpost/blob/main/core/pki/document.go#L77

which contains many MixDescriptor objects for the entire network:
https://github.com/katzenpost/katzenpost/blob/main/core/pki/document.go#L128

Currently all network components use Sphinx with a geometry that is 
hardcoded. However I've got a work-in-progress branch where I'm changing 
things to distribute the Sphinx geometry in the directory authority 
document:

https://github.com/katzenpost/katzenpost/blob/sphinx_geo_pki/core/sphinx/geo/geo.go#L31-L89

https://github.com/katzenpost/katzenpost/blob/sphinx_geo_pki/core/pki/document.go#L152

The Sphinx Geometry describes it's KEM or NIKE:
https://github.com/katzenpost/katzenpost/blob/sphinx_geo_pki/core/sphinx/geo/geo.go#L82-L88

So I guess my question is: How shall I marshal/unmarshal a map of public 
keys where the keys themselves can be any type that satisfies our NIKE 
interface or KEM inteface?

It would be silly to put a bunch of concrete key maps into MixDescriptor. 
There will always be more KEMs and NIKEs.

It sounds like I need change the MixKeys field of the MixDescriptor to use 
a wrapper type instead of a map directly. The wrapper type would have it's 
own UnmarshalBinary/MarshalBinary (so that cbor.Marshal/Unmarshal can be 
called) which would represent the map as a list of two tuples: key, value. 
Easy to convert it to a map.

What do you think of this approach?

type KeyValue struct {
Key uint64
Value mixkey.PublicKey
}

...blah blah...

fubar := make([]KeyValue, 123)
cbor.Unmarshal(blob, fubar)

But can this work if mixkey.PublicKey is an interface? Nope. I don't think 
that works because the nil value of KeyValue struct will have a nil for 
it's Value field.

Any suggestions?

Cheers,

David

-- 
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/0f0cb548-66ce-4499-91ef-3faa497ad41cn%40googlegroups.com.

Re: [go-nuts] Silly question about parentheses

[David Finkel]

On Wed, Feb 1, 2023 at 11:22 AM Chris Burkert 
wrote:

> Looking into the spec:
>
> https://go.dev/ref/spec#Return_statements
> ReturnStmt = "return" [ ExpressionList ] .
> ExpressionList = Expression { "," Expression } .
> ... no () here
>
> https://go.dev/ref/spec#Function_types
> FunctionType   = "func" Signature .
> Signature  = Parameters [ Result ] .
> Result = *Parameters | Type* .
> Parameters = *"("* [ ParameterList [ "," ] ] *")"* .
> ParameterList  = ParameterDecl { "," ParameterDecl } .
> ParameterDecl  = [ IdentifierList ] [ "..." ] Type .
> ... a *Type* does not need () but *Parameters* needs them.
>
> But now I am puzzled. I can actually omit the variable name for the
> arguments: https://play.golang.com/p/g4Sz8rh06QW.
>
> This seems to be useless, but it is actually allowed, right?
>

It's not useless because sometimes you need to take a specific
parameter-list to satisfy an interface, but that specific implementation
doesn't need that input.
Similarly, when defining a method in an interface
, sometimes the type says it all, so
there's no value in defining a name for the argument.

Note: I'm not saying that one should never name variables in interface
definitions, so much that in some cases, it's clearer with just types.
  There are definitely many interface definitions that are
underspecified without argument-names)


> Am Mi., 1. Feb. 2023 um 17:04 Uhr schrieb Raphael Clancy <
> raphael.cla...@gmail.com>:
>
>> This is really helpful! Thank you!
>>
>> At first I assumed that it was down to 'go fmt' letting you be fairly
>> loose with your syntax and that you could omit parentheses where the
>> meaning wouldn't be ambiguous.  But on closer examination, there must be
>> something else going on because 'return a, b' works fine and 'return (a,
>> b)' generates an error. But, both 'func(a string) string {}' and  'func(a
>> string) (string){}' work fine.
>>
>> Maybe it's because 'return' isn't really a function call and has it's own
>> syntax?
>>
>> On Wednesday, February 1, 2023 at 8:13:10 AM UTC-7
>> axel.wa...@googlemail.com wrote:
>>
>>> Good point, didn't think of that
>>>
>>> On Wed, Feb 1, 2023, 15:30 p...@morth.org  wrote:
>>>
 It would actually be ambiguous in the very place they're required.

 Consider this not completely unreasonable example:
 https://go.dev/play/p/OL0uOnPZXju

 Also, with generics it could be ambiguous in type parameters.
 To summarize, parentheses are needed around the return types because
 otherwise anywhere a list of types is used, it would be ambiguous.

 Regards,
 Per Johansson

 On Tuesday, January 31, 2023 at 8:38:46 PM UTC+1
 axel.wa...@googlemail.com wrote:

> I'm not sure there really is a "reason", per se. The language could
> just as well have been designed not to require parentheses around the
> return types (at least I see no parsing ambiguity with that, though there
> might be) or designed to require parentheses in the return statement. It
> probably just felt more intuitive and readable to the designers at the 
> time.
>
> FWIW I find it more interesting that `func() T` requires no
> parentheses, but `func() (S, T)` does.
>
> On Tue, Jan 31, 2023 at 5:55 PM Raphael Clancy 
> wrote:
>
>> Hey all, I figured it was time to move to a "modern" language and I
>> thought I'd give go a try. So far, I'm really enjoying it. I'm just 
>> getting
>> started and I had a question about parentheses. Though, I guess it's 
>> really
>> about how go parses lines of code and what counts as a delimiter.
>>
>> Anyway, in the get started section on error handling
>> , why are parentheses
>> required around string and error here:
>>
>> func Hello(name string) (string, error) {...
>>
>> but not around message and nil here:
>>
>> return message, nil
>>
>> I tried searching a bit but I couldn't come up with anything about
>> such a basic topic.
>>
>> 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...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/b49dc8c2-26ea-46bc-b76a-708a2537207cn%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 

Re: [go-nuts] Clarification of memory model behavior within a single goroutine

['David Klempner' via golang-nuts]

On Mon, Jan 23, 2023 at 11:38 AM Robert Engels 
wrote:

> The atomic functions force a memory barrier when atomically in conjunction
> with the atomic read of the same value.
>
> You could use CGO to call a C function to do what you desire - but it
> shouldn’t be necessary.
>

C doesn't solve this problem, unless your "C function" is something like an
"asm volatile". C has the exact same underlying issue as Go here -- the
language does not define interprocess atomics, because doing so is hard.

In practice you can probably do the equivalent of a sequentially consistent
store on the writer side and a sequentially consistent read on the other,
and things will likely work.

With that said, that doesn't strictly work even for two C programs. As a
concrete example, if you're implementing sequentially consistent atomics on
x86, while read-modify-write instructions don't need any extra fencing, you
have to choose whether to make reads expensive (by adding a fence on reads)
or writes expensive (by adding a fence on writes). While in practice every
implementation chooses to make the writes expensive, that is an
implementation decision and nothing stops someone from making a
reads-expensive-writes-cheap compiler.

If a "writes cheap compiler" program does an atomic write over shared
memory to a "reads cheap compiler" program, there won't be any fences on
either side and you won't get sequential consistent synchronization.
(That's fine for a simple producer-consumer queue as in this example which
only requires release-acquire semantics, but fancier algorithms that rely
on sequential consistency will be quite unhappy.)


>
> Not sure what else I can tell you.
>
> On Jan 22, 2023, at 8:12 PM, Peter Rabbitson  wrote:
>
> 
> On Mon, Jan 23, 2023 at 12:42 AM robert engels 
> wrote:
>
>> Write data to memory mapped file/shared memory. Keep track of last
>> written byte as new_length;
>>
>> Use atomic.StoreUint64(pointer to header.length, new_length);
>>
>>
> This does not answer the question I posed, which boils down to:
>
> How does one insert the equivalent of smp_wmb() /
> asm volatile("" ::: "memory") into a go program.
>
> For instance is any of these an answer?
> https://groups.google.com/g/golang-nuts/c/tnr0T_7tyDk/m/9T2BOvCkAQAJ
>
>
>> readers read ...
>>
>
> Please don't focus on the reader ;)
>
>
>> This assumes you are always appending ,,, then it is much more
>> complicated ... all readers have consumed the data before the writer reuses
>> it.
>>
>
> Yes, it is much more complicated :) I am making a note to post the result
> back to this thread in a few weeks when it is readable enough.
>
> --
> 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/5F73A3C7-32C3-42A1-91A2-E1A0714FAEA5%40ix.netcom.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/CAMbN1s5SAtWzgajE7ZCN_z-h2ABkQ5GWgx5%3DX7ehVQo-sOy82g%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[go-nuts] the example always fails if the string contains a trailing space before a newline

[David M]

Not quite sure if this is a bug but it's annoying:

If the example tested string contains a trailing space before a newline, 
the test always fails no matter how.
// this test passes 
func ExampleFormat() {
fmt.Println("a\nb")
// Output:
// a 
// b 
}
// this test fails no matter we put "a" or "a " in the first output line. 
func ExampleFormat() { 
fmt.Println("a \nb") 
// Output:
// a
// b
 }

The doc  says "The comparison 
ignores leading and trailing space." I guess what's going on here is that 
it cut the trailing space in the desired output, but doesn't handle the 
space in the practical output if it's before a newline. Because the 
practical output may come from a 3rd party library, we have to respect how 
they print things.

-- 
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/c24ffdb6-bde2-43be-b2ed-9735752bfb95n%40googlegroups.com.

Re: [go-nuts] cgo C.uint64_t compatiblity on multiple platforms?

[David Stainton]

Thanks, yes switching those type casts to C.size_t worked.

On Saturday, December 3, 2022 at 2:39:24 PM UTC-5 kortschak wrote:

> On Sat, 2022-12-03 at 10:51 -0800, David Stainton wrote:
> > Greetings,
> >
> > I think my question is something like: "how to make my usage of
> > C.uint64_t work on all platforms?" or "Is there something obviously
> > wrong with my cgo bindings that is causing this not to build on all
> > platforms?"
> >
> > I wrote this cgo binding for the reference implementation of Sphincs+
> > (it's a hash based post quantum signature scheme):
> >
> > 
> https://github.com/katzenpost/katzenpost/blob/main/sphincsplus/ref/binding.go
> >
> > Recently we noticed it fails to build on MacOS and Windows:
> >
> > 
> https://github.com/katzenpost/katzen/actions/runs/3609590801/jobs/6082872618
> >
> > So I "fixed" it by changing the typecast to use C.uint64_t instead of
> > C.ulong:
> >
> > https://github.com/katzenpost/katzenpost/pull/110/files
> >
> > However that causes the build to fail using Go1.19.3 on MacOS,
> > although it works on Windows:
> >
> > 
> https://github.com/katzenpost/katzen/actions/runs/3609771045/jobs/6083165054
> >
> >
> > Sincerely,
> > David Stainton
>
> The header file definition for crypto_sign_signature uses size_t for
> the parameters that are passed as ulong in the calls that are causing
> the issue. These types are not always the same size, so perhaps in e.g.
>
> https://github.com/katzenpost/katzenpost/blob/a165cb2a13e40f3a15dd1fa296a7763d8b638ae0/sphincsplus/ref/binding.go#L120-L125
> making the ulong params be size_t would help.
>
>

-- 
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/ff839488-59ff-45d8-bd01-ebc47a9a473an%40googlegroups.com.

[go-nuts] cgo C.uint64_t compatiblity on multiple platforms?

[David Stainton]

Greetings,

I think my question is something like: "how to make my usage of C.uint64_t 
work on all platforms?" or "Is there something obviously wrong with my cgo 
bindings that is causing this not to build on all platforms?"

I wrote this cgo binding for the reference implementation of Sphincs+ (it's 
a hash based post quantum signature scheme):

https://github.com/katzenpost/katzenpost/blob/main/sphincsplus/ref/binding.go

Recently we noticed it fails to build on MacOS and Windows:

https://github.com/katzenpost/katzen/actions/runs/3609590801/jobs/6082872618

So I "fixed" it by changing the typecast to use C.uint64_t instead of 
C.ulong:

https://github.com/katzenpost/katzenpost/pull/110/files

However that causes the build to fail using Go1.19.3 on MacOS, although it 
works on Windows:

https://github.com/katzenpost/katzen/actions/runs/3609771045/jobs/6083165054


Sincerely,
David Stainton

-- 
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/86bdb5ce-d4ce-474e-bc98-01f7a8dce9fcn%40googlegroups.com.

Re: [go-nuts] Re: Go implementation of CLP

[david lion]

Ah, the parsing component doesn't include search, but it is a necessary 
part to enable searching compressed logs. CLP's searching of compressed 
logs is enabled by the storage format it uses (as it both compresses and 
indexes the logs). The parsing component is how we extract information from 
the logs necessary for the storage format.

We can write bindings for search as well---we only started with compression 
because that's what we had more requests for. To focus our effort, could 
you let us know more about what kind of queries you want to run? The 
open-source C++ code supports wildcard queries but some users prefer 
grep-like regex, SQL-like boolean expressions, etc. We haven't yet settled 
on one, especially for a binding that needs to be somewhat stable.

On Friday, 18 November 2022 at 20:09:06 UTC-5 Jason E. Aten wrote:

> Sorry for not being familiar with the terminology. I thought the search 
> through compressed logs was the most interesting part. Is that included in 
> the "parsing component"?
>
> On Fri, Nov 18, 2022 at 1:21 PM david lion  wrote:
>
>> At the moment we're working on a Go binding around the parsing component 
>> of CLP.
>> You're right, the current code is all C++, but we'll be moving the 
>> parsing component to be standalone and creating a C API for it.
>>
>> Right now, we're only creating bindings for the parsing component since 
>> it seems to be the common element in the use-cases we have come across, but 
>> we'd love to hear about any use-cases you're interested in and how we could 
>> support them. For example, with SeaweedFS it makes more sense to integrate 
>> most of the CLP logic directly into the filesystem itself.
>>
>> On Sunday, 13 November 2022 at 04:28:12 UTC-5 Jason E. Aten wrote:
>>
>>> CLP looks impressive. 
>>>
>>> Is there is a C API then it would probably be easy to write Go bindings 
>>> to it.
>>>
>>> Since there is some kind of python integration, perhaps a C API is 
>>> already there.
>>> I took a quick look but could only see C++ code; it would have to be an 
>>> actual C (not C++) API for cgo to be usable.
>>>
>>> Usually this is not too difficult to add to a C++ project.
>>>
>>> On Wednesday, November 9, 2022 at 2:14:03 AM UTC-6 Bharghava Varun Ayada 
>>> wrote:
>>>
>>>> I'm exploring CLP for a logging platform and I think either a cgo or 
>>>> native go library might be something that would help us.
>>>>
>>>> On Tuesday, 4 October 2022 at 22:03:34 UTC+5:30 david...@gmail.com 
>>>> wrote:
>>>>
>>>>> It would be awesome to help SeaweedFS, so I'm eager to hear more about 
>>>>> your ideas to try and understand anything we can do.
>>>>>
>>>>> Sorry if some of my questions are naive. At a high level I'm trying to 
>>>>> better understand two topics:
>>>>> 1. the use cases (or features) we/CLP can help with
>>>>> 2. the technical aspects/limitations that make a pure-go 
>>>>> implementation necessary/beneficial
>>>>>
>>>>> I saw that SeaweedFS currently can automatically compresses certain 
>>>>> file types with Gzip (very cool btw).
>>>>> I can imagine that augmenting this feature with CLP for log file types 
>>>>> could be beneficial.
>>>>> Are these the log files you're referring to? Does SeaweedFS itself 
>>>>> also produce log files that can benefit from CLP? Perhaps CLP could help 
>>>>> with both cases?
>>>>>
>>>>> As I imagine packaging the current form of CLP with SeaweedFS is 
>>>>> awkward, is packaging a main reason for a pure-go implementation?
>>>>> Would a library with programmatic API be favourable for integration 
>>>>> rather than calling out to another tool/executable (as required in CLP's 
>>>>> current form)?
>>>>> Would a go package using cgo (to reuse some existing cpp code) be 
>>>>> desirable or is there a requirement for strictly go code?
>>>>>
>>>>> -david
>>>>>
>>>>> On Sunday, 2 October 2022 at 22:36:38 UTC-4 ChrisLu wrote:
>>>>>
>>>>>> Thanks! CLP is great! 
>>>>>>
>>>>>> I am working on a distributed file system, SeaweedFS, 
>>>>>> https://github.com/seaweedfs/seaweedfs
>>>>>> I am interested in a pure-go implementation to store the log files 
>>>>>> more efficient

Re: [go-nuts] Re: Go implementation of CLP

[david lion]

At the moment we're working on a Go binding around the parsing component of 
CLP.
You're right, the current code is all C++, but we'll be moving the parsing 
component to be standalone and creating a C API for it.

Right now, we're only creating bindings for the parsing component since it 
seems to be the common element in the use-cases we have come across, but 
we'd love to hear about any use-cases you're interested in and how we could 
support them. For example, with SeaweedFS it makes more sense to integrate 
most of the CLP logic directly into the filesystem itself.

On Sunday, 13 November 2022 at 04:28:12 UTC-5 Jason E. Aten wrote:

> CLP looks impressive. 
>
> Is there is a C API then it would probably be easy to write Go bindings to 
> it.
>
> Since there is some kind of python integration, perhaps a C API is already 
> there.
> I took a quick look but could only see C++ code; it would have to be an 
> actual C (not C++) API for cgo to be usable.
>
> Usually this is not too difficult to add to a C++ project.
>
> On Wednesday, November 9, 2022 at 2:14:03 AM UTC-6 Bharghava Varun Ayada 
> wrote:
>
>> I'm exploring CLP for a logging platform and I think either a cgo or 
>> native go library might be something that would help us.
>>
>> On Tuesday, 4 October 2022 at 22:03:34 UTC+5:30 david...@gmail.com wrote:
>>
>>> It would be awesome to help SeaweedFS, so I'm eager to hear more about 
>>> your ideas to try and understand anything we can do.
>>>
>>> Sorry if some of my questions are naive. At a high level I'm trying to 
>>> better understand two topics:
>>> 1. the use cases (or features) we/CLP can help with
>>> 2. the technical aspects/limitations that make a pure-go implementation 
>>> necessary/beneficial
>>>
>>> I saw that SeaweedFS currently can automatically compresses certain file 
>>> types with Gzip (very cool btw).
>>> I can imagine that augmenting this feature with CLP for log file types 
>>> could be beneficial.
>>> Are these the log files you're referring to? Does SeaweedFS itself also 
>>> produce log files that can benefit from CLP? Perhaps CLP could help with 
>>> both cases?
>>>
>>> As I imagine packaging the current form of CLP with SeaweedFS is 
>>> awkward, is packaging a main reason for a pure-go implementation?
>>> Would a library with programmatic API be favourable for integration 
>>> rather than calling out to another tool/executable (as required in CLP's 
>>> current form)?
>>> Would a go package using cgo (to reuse some existing cpp code) be 
>>> desirable or is there a requirement for strictly go code?
>>>
>>> -david
>>>
>>> On Sunday, 2 October 2022 at 22:36:38 UTC-4 ChrisLu wrote:
>>>
>>>> Thanks! CLP is great! 
>>>>
>>>> I am working on a distributed file system, SeaweedFS, 
>>>> https://github.com/seaweedfs/seaweedfs
>>>> I am interested in a pure-go implementation to store the log files more 
>>>> efficiently.
>>>>
>>>> Chris
>>>>
>>>> On Sun, Oct 2, 2022 at 6:45 PM david lion  wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> I'm one of the CLP developers. We'd be interested in hearing your use 
>>>>> case and any features you'd like implemented in CLP.
>>>>> As for a Go implementation, are you asking about bindings to directly 
>>>>> call CLP functionality from a Go program or are you interested in a 
>>>>> complete re-write in Go?
>>>>>
>>>>> -david
>>>>>
>>>>> On Friday, 30 September 2022 at 03:58:44 UTC-4 ChrisLu wrote:
>>>>>
>>>>>> Seems there are no Go implementation for Compressed Log Processor 
>>>>>> (CLP) yet? 
>>>>>>
>>>>>> CLP is a tool capable of losslessly compressing text logs and 
>>>>>> searching the compressed logs without decompression.
>>>>>>
>>>>>> https://github.com/y-scope/clp
>>>>>>
>>>>>> Chris
>>>>>>
>>>>> -- 
>>>>> You received this message because you are subscribed to a topic in the 
>>>>> Google Groups "golang-nuts" group.
>>>>> To unsubscribe from this topic, visit 
>>>>> https://groups.google.com/d/topic/golang-nuts/XeDIZfTMlX8/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, send an email to 
>>>>> golang-nuts...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/golang-nuts/0c57905a-1096-4688-b268-93742c48316fn%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/golang-nuts/0c57905a-1096-4688-b268-93742c48316fn%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>>

-- 
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/82c4077a-e6ce-4ac6-b944-cd5ef792a394n%40googlegroups.com.

[go-nuts] Re: checkptr reports error in lfstack_64bit.go

[David Pacheco]

Hi Keith,

Thanks for the helpful (and quick) reply!  I gather you're right about not 
applying checkptr to Go's own test suite.  I applied your patch, tried 
again, and started hitting failures in tests that were written for specific 
past issues.  These seem like false positives.

Do you have other suggestions for how to debug this problem?  I tried 
checkptr because when I ran the test suite and it failed with a panic 
message, that's what the panic message from the runtime said to try.

Thanks!

-- Dave

On Tuesday, November 8, 2022 at 5:53:22 PM UTC-8 k...@google.com wrote:

>
> Should be fixed by https://go-review.googlesource.com/c/go/+/448899
>
> On Tuesday, November 8, 2022 at 4:34:00 PM UTC-8 Keith Randall wrote:
>
>> (Although normally lfstack nodes should not be heap allocated in the 
>> first place?)
>>
>>
>> On Tuesday, November 8, 2022 at 4:32:11 PM UTC-8 Keith Randall wrote:
>>
>>> I don't think checkptr is intended to be applied blindly inside the 
>>> runtime. The lfstack code is definitely doing things that checkptr was 
>>> designed to catch and flag.
>>> Maybe the lfstack routines need a go:nocheckptr annotation?
>>>
>>> On Tuesday, November 8, 2022 at 11:21:30 AM UTC-8 David Pacheco wrote:
>>>
>>>> Hello,
>>>>
>>>> I’m trying to track down an issue reported by the Go memory allocator.  
>>>> Most of the failure modes look like this one:
>>>> https://github.com/golang/go/issues/53289#issuecomment-1292744833
>>>> but some of them look like:
>>>> https://github.com/golang/go/issues/53289#issuecomment-1289743609
>>>>
>>>> It looks to me like these could be different manifestations of the same 
>>>> issue.  Following the advice in the second message, I tried to build Go 
>>>> and 
>>>> run the test suite with `export GO_GCFLAGS="-d=checkptr"` in 
>>>> src/make.bash. 
>>>>  With that, I saw checkptr fail:
>>>>
>>>> fatal error: checkptr: pointer arithmetic result points to invalid 
>>>> allocation
>>>>
>>>> goroutine 23171 [running]:
>>>> runtime.throw({0x8198ae?, 0xc0001560cf?})
>>>> 
>>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/panic.go:1047
>>>>  
>>>> +0x5d fp=0xc0029f4e70 sp=0xc0029f4e40 pc=0x43c95d
>>>> runtime.checkptrArithmetic(0x770f40?, {0x0, 0x0, 0x0?})
>>>> 
>>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/checkptr.go:70
>>>>  
>>>> +0xea fp=0xc0029f4eb0 sp=0xc0029f4e70 pc=0x40856a
>>>> runtime.lfstackUnpack(...)
>>>> 
>>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/lfstack_64bit.go:52
>>>> runtime.(*lfstack).pop(...)
>>>> 
>>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/lfstack.go:47
>>>> runtime.LFStackPop(...)
>>>> 
>>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/export_test.go:70
>>>> runtime_test.TestLFStack(0xc000d26b60)
>>>> 
>>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/lfstack_test.go:52
>>>>  
>>>> +0x2de fp=0xc0029f4f70 sp=0xc0029f4eb0 pc=0x6deb9e
>>>> testing.tRunner(0xc000d26b60, 0x820dc0)
>>>> 
>>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/testing/testing.go:1446
>>>>  
>>>> +0x10b fp=0xc0029f4fc0 sp=0xc0029f4f70 pc=0x4fd94b
>>>> testing.(*T).Run.func1()
>>>> 
>>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/testing/testing.go:1493
>>>>  
>>>> +0x2a fp=0xc0029f4fe0 sp=0xc0029f4fc0 pc=0x4fe7ea
>>>> runtime.goexit()
>>>> 
>>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/asm_amd64.s:1594
>>>>  
>>>> +0x1 fp=0xc0029f4fe8 sp=0xc0029f4fe0 pc=0x476121
>>>> created by testing.(*T).Run
>>>>
>>>> That points to this code:
>>>>
>>>> https://github.com/golang/go/blob/39ac1fbd1393deed245dcf653220b14376f6/src/runtime/lfstack_64bit.go#L52
>>>>
>>>> So I dug into the checkptr check and added some more printlns and I 
>>>> found that this appears to be a heap address (0xc0001560c0), and 
>>>> “originals” is empty (in checkptrArithmetic).  Given that, I’m not sure 
>>>> how 
>>>> this could ever work, since “originals” seems to come from the compiler 
>>>> (so 
>>>> it doesn’t depend on runtime state).  Can someone point me in the right 
>>>> direction to better understanding what’s wrong here?  Alternatively, is 
>>>> there other information that would be useful to debug this problem?
>>>>
>>>> Thanks,
>>>> Dave
>>>>
>>>

-- 
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/7a54a621-b7bb-4965-9037-63f19795d2d1n%40googlegroups.com.

Re: [go-nuts] Underscore symbol

[David Finkel]

On Sat, Nov 5, 2022 at 4:57 AM Chris Burkert 
wrote:

> I am curious: from a compiler perspective, does that mean that by using _
> simply less assembler instructions are created by not handling those
> registers which relate to _?
>
>
That kind of depends on what you mean by "not handling". Since it's a
compile-time error (in the GC compiler) to have an unused variable, you'd
have to do something else with that value.
Depending on what type that ignored return value is, whether the call is
inlined and whether the call is using the newer, register-based calling
convention the compiler *may* be able to prune instructions related to that
variable.

Here are a few scenarios off the top of my head (in no particular order and
by no means exhaustive, but some of them are interesting -- and some are
completely hypothetical optimizations as I haven't looked at a lot of the
relevant compiler code myself):

   - The call doesn't get inlined, and it's a trivial value that can be
   passed around in a register, so that return register is simply never read
   (and gets clobbered at some later point when it's needed)
   - The call is inlined, and the variable that it's returned from doesn't
   interact with anything in the callee, so the code for generating that
   return variable can be removed during a dead-code removal pass
   - The call is inlined and that return value is a pointer to something on
   the heap, in which case the stack pointer-liveness map for that point in
   the function will mark that pointer as dead (I'm not certain about this
   one) -- this might let the heap object get GC'd from that moment.
   - The call is assembly so it's eligible for neither the newer
   register-calling convention nor inlining, so the spot on the stack for that
   return value just gets ignored until the function returns (or that
   stack-space gets allocated to another variable)
   - cgo can't return multiple values, but if you ignore the return value
   in AMD64 calling conventions it's a register that can be ignored. (although
   it may be a pointer to something elsewhere in memory, in which case gets
   more interesting)
   - The call is inlined and the return value is a pointer which would
   normally be marked as escaping but because the pointer gets ignored, the
   compiler can go back to stack-allocating. (I'm not sure if the compiler has
   a second escape-analysis pass like this, but it could be interesting)


Marcel Huijkman  schrieb am Sa. 5. Nov. 2022
> um 09:18:
>
>> When I explain it during my training I always say it is a trashcan
>> variable, anything you put in is to be ignored on the spot.
>>
>> On Friday, November 4, 2022 at 10:10:20 PM UTC+1 Konstantin Khomoutov
>> wrote:
>>
>>> On Fri, Nov 04, 2022 at 04:58:35AM -0700, Canuto wrote:
>>>
>>> > I'm just starting out with go ...
>>> > I have searched for lights on this string but without success.
>>> > What does this sign mean " _, err " , what the underscore symbol means
>>> here?
>>>
>>> If you're starting with Go, please start with the Go Tour [1].
>>> For instance, the use of this underscore sign is covered in [2].
>>>
>>> 1. https://go.dev/tour/
>>> 2. https://go.dev/tour/moretypes/17
>>>
>>> --
>> 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/6c745c54-b212-4bb6-8e40-00273e6ee2fan%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/CALWqRZo-n%3D_16Ug8Rids3E502dFZcW5PPZueGKfDqA%2Bcg30X6A%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/CANrC0BjkRus%2B-kV5Wdq7vwiLinqiuRyX7o5LbtXnDh_BHqD%2BxQ%40mail.gmail.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] Any information about adding a trailing comma in ast CompositeLit (for structs)

[David Finkel]

On Mon, Oct 24, 2022 at 9:27 PM Tajmeet Singh  wrote:

> Thanks for looking at it :smile:
>
> Could you elaborate more on how the `SetLines` would work on a
> `token.FileSet`? I thought that `SetLines` is only for the `os.File` types
> :sweat: Do you mean that I should create offsets (using SetLines) before I
> create the FileSet out of it?
>
Sure, so what I was thinking is that you'd use a different fileset than the
one used to parse the AST, and only give it synthetic line-boundaries (the
line-widths don't actually have to make sense), and then, when picking the
token locations for the different elements in the CompositeLiteral, you'd
override the locations of those tokens in the AST so nodes you want to
appear on the same line will appear on the same line. (up to formatting
constraints)

Another other option (which is much simpler -- and I wish I had thought of
before) is to pass the ast.FieldList <https://pkg.go.dev/go/ast#FieldList>
from the StructType <https://pkg.go.dev/go/ast#StructType.Fields> instead
of the slice of fields, then you can use the token.Pos from the Closing
field <https://pkg.go.dev/go/ast#FieldList.Closing>. If you use Pos()
<https://pkg.go.dev/go/ast#Field.Pos> for the field to set the `Colon
<https://pkg.go.dev/go/ast#KeyValueExpr.Colon>` field on the KeyValueExpr
<https://pkg.go.dev/go/ast#KeyValueExpr.Colon>, the formatter will see the
line boundaries in between fields as appropriate and match the formatting
of the struct definition. (AFAICT)


>
> reference code:
> https://github.com/tjgurwara99/constr/blob/0e0f8952c652b7a7a10b7238daed90132b924084/construct.go#L31
>
> On Tuesday, 25 October 2022 at 01:07:23 UTC+1 david@gmail.com wrote:
>
>> On Sat, Oct 22, 2022 at 10:00 PM Tajmeet Singh 
>> wrote:
>>
>>> Hello,
>>>
>>> I've been working on a utility to generate constructors for me when I
>>> provide it with a path to the file containing the struct and it `Ident`.
>>> The idea was that I would just create a ast.Node (FuncDecl) with all the
>>> necessary fields but I'm not able to figure out the positioning of the
>>> commas.
>>>
>>> The function that I'm working on looks something like this:
>>>
>>> ```Go
>>> func generateConstructor(typeName string, fields ...*ast.Field)
>>> *ast.FuncDecl {
>>> var elts []ast.Expr
>>>
>>> for _, field := range fields {
>>> elts = append(elts, {
>>> Key:   field.Names[0],
>>> Value: field.Names[0],
>>> })
>>> }
>>> return {
>>> Doc:  nil,
>>> Recv: nil,
>>> Name: ast.NewIdent("New" + typeName),
>>> Type: {
>>> TypeParams: nil,
>>> Params: {
>>> List: fields,
>>> },
>>> Results: nil,
>>> },
>>> Body: {
>>> Lbrace: 1,
>>> List: []ast.Stmt{
>>> {
>>> Results: []ast.Expr{
>>> {
>>> Op: token.AND,
>>> X: {
>>> Type:   ast.NewIdent(typeName),
>>> Elts:   elts,
>>> Rbrace: 1,
>>> },
>>> },
>>> },
>>> },
>>> },
>>> Rbrace: 2,
>>> },
>>> }
>>> }
>>> ```
>>>
>>> And when I provide it with a struct like this:
>>>
>>> ```Go
>>> type Data struct {
>>> something string
>>> data  string
>>> ddint
>>> }
>>> ```
>>> I get this when I do `format.Node` on the generated node `functionDecl`.
>>>
>>> ```Go
>>> func NewData(something string,
>>> data string,
>>> dd int) {
>>> return {something: something,
>>> data: data,
>>> dd: dd}
>>> }
>>> ```
>>>
>>> However, I was thinking that it would look something like this.
>>>
>>> ```Go
>>> func NewData(something string,
>>> data string,
>>> dd int,
>>> ) {
>>> return {something: something,
>>> data: data,
>>> dd: dd,
>>> }
>>> }
>>> ```
&

Re: [go-nuts] Analyse postgresql error

[David Harel]

Thanks for your reply.

After I submitted my question I made some progress and found that:
The infrastructure of my solution is using the pq package - import "
github.com/lib/pq"
The marshaling method is not relevant anymore.
I can analyse the error by casting to pq.Error.

Code example:

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?


On Tue, Oct 25, 2022 at 7:21 PM Konstantin Khomoutov 
wrote:

> On Fri, Oct 21, 2022 at 08:17:16AM -0700, David Harel wrote:
>
> > Newbie on golang. Using sqlc: https://github.com/kyleconroy/sqlc in the
> > environment created by Karl Keefer:
> > https://github.com/karlkeefer/pngr/actions/workflows/build.yml, thanks
> Karl.
> > My queries use querier which is auto generated by sqlc.
> >
> > Sometime I get an error result in my query such as key violation.
> > I want to check the error code of such an error.
> >
> > as one of the guys suggested I can look into the object using Marshal
> > and I noticed that the error contains a very elaborated, like:
> > {"Severity":"ERROR","Code":"23505","Message":"duplicate key value
> violates
> > unique constraint \"treatment_pk\"","Detail":"Key (customer_id,
> patient_ttz,
> > therapist_id, appointment_timestamp)=(1, 060525649, 160, 2022-10-20
> > 10:30:00) already
> > exists.","Hint":"","Position":"","InternalPosition":"",
> > "InternalQuery":"","Where":"","Schema":"public",
> > "Table":"treatment","Column":"","DataTypeName":"",
> > "Constraint":"treatment_pk","File":"nbtinsert.c","Line":"434",
> > "Routine":"_bt_check_unique"}
>
> What is "Marshal" you're referring to here?
> Is this encoding/json.Marshal called on some value returned by that
> "querier generated by sqlc"?
>
> > Trying to get the same result using straight forward approach like:
> > fmt.Printf("%+v\n", err) gives me a much simpler object display.
> >
> > How can I get the "smart" content of the error object like the "Code"
> > member?
>
> If my guesseneering is correct, you can just access the Code field of that
> value you passed through "Marshal" and analyze it using any convenient
> method
> such as an if or switch statement.
>
> From [1], I gather that "23505" is indeed a standardized error code for
> violation of unique key constraints in PostgreSQL, so basically you could
> do
>
>   const uniqueKeyViolation = "23505"
>
>   switch result.Code {
>   case uniqueKeyViolation:
> // Do something sensible
>   default:
> log.Println("unexpected failure: ", result.Code)
>   }
>
> Still, please notice that all of the above is what's called "psychic
> debugging" and might miss the point partially or completely because your
> problem statement is not an MCVE [2]. I'm not sure you could sensibly
> create
> one (as it could have required posting swaths of generated code or
> something
> like this) so please don't take it as a blame.
>
>  1. https://www.postgresql.org/docs/current/errcodes-appendix.html
>  2. https://stackoverflow.com/help/minimal-reproducible-example
>
>

-- 
דוד הראל
עמוקה
ד.נ. מרום הגליל
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_%3DOZx7apxRe2fW9q5Uqxou-1PnGRSyZLJer6Ha09MEpe7%3Dg%40mail.gmail.com.

Re: [go-nuts] Any information about adding a trailing comma in ast CompositeLit (for structs)

[David Finkel]

On Sat, Oct 22, 2022 at 10:00 PM Tajmeet Singh 
wrote:

> Hello,
>
> I've been working on a utility to generate constructors for me when I
> provide it with a path to the file containing the struct and it `Ident`.
> The idea was that I would just create a ast.Node (FuncDecl) with all the
> necessary fields but I'm not able to figure out the positioning of the
> commas.
>
> The function that I'm working on looks something like this:
>
> ```Go
> func generateConstructor(typeName string, fields ...*ast.Field)
> *ast.FuncDecl {
> var elts []ast.Expr
>
> for _, field := range fields {
> elts = append(elts, {
> Key:   field.Names[0],
> Value: field.Names[0],
> })
> }
> return {
> Doc:  nil,
> Recv: nil,
> Name: ast.NewIdent("New" + typeName),
> Type: {
> TypeParams: nil,
> Params: {
> List: fields,
> },
> Results: nil,
> },
> Body: {
> Lbrace: 1,
> List: []ast.Stmt{
> {
> Results: []ast.Expr{
> {
> Op: token.AND,
> X: {
> Type:   ast.NewIdent(typeName),
> Elts:   elts,
> Rbrace: 1,
> },
> },
> },
> },
> },
> Rbrace: 2,
> },
> }
> }
> ```
>
> And when I provide it with a struct like this:
>
> ```Go
> type Data struct {
> something string
> data  string
> ddint
> }
> ```
> I get this when I do `format.Node` on the generated node `functionDecl`.
>
> ```Go
> func NewData(something string,
> data string,
> dd int) {
> return {something: something,
> data: data,
> dd: dd}
> }
> ```
>
> However, I was thinking that it would look something like this.
>
> ```Go
> func NewData(something string,
> data string,
> dd int,
> ) {
> return {something: something,
> data: data,
> dd: dd,
> }
> }
> ```
> (wishful thinking :joy:)
>
> Anyways, I tried to figure out how the `token.COMMA` is used in the parser
> and how the ast is affected but I couldn't figure it out. Maybe it is
> related to the `Lbrace` and `Rbrace` values which I'm deliberately missing.
> Any help would be much appreciated :smile: :pray:
>

Looking at the code, I think you're on the right track with Rbrace's
location being the determining factor when to insert a comma and move put
the closing brace on a new line.
My recommendation would be to use `SetLines`
 on the (hopefully
clean) `token.FileSet` you're passing to `format.Node` to declare some
new-line offsets. I don't think the offsets have to make sense as they
would in a file that was parsed, but the formatter needs to see the last
expression and close brace as being on different lines

The type-switch line that handles CompositeLit's call handling insertions:
https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/go/printer/nodes.go;l=1021;drc=7e72d384d66f48a78289edc6a7d1dc6ab878f990
The lines that handle making the decision about inserting a new line:
https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/go/printer/nodes.go;l=297-299;drc=a1901f898bc05aac966edd247ff122f52fbb8d2e

>
> PS: I'm not aware of any utility out there so have to roll my own :joy:
> and learn whilst at it; if people are aware of it, please let me know and
> I'll inspect their code and figure things out :smile:
>
> --
> 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/ffa312d0-5652-4c2d-9c71-c74bc4bfc56bn%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/CANrC0BgETovBLDUFrQeEEbCEgtoA7qWTOUgq-Wft4%2B%2Bxn1MRfg%40mail.gmail.com.

[go-nuts] Analyse postgresql error

[David Harel]

Hi there,

Newbie on golang. Using sqlc: https://github.com/kyleconroy/sqlc in the 
environment created by Karl Keefer: 
https://github.com/karlkeefer/pngr/actions/workflows/build.yml, thanks Karl.
My queries use querier which is auto generated by sqlc.

Sometime I get an error result in my query such as key violation.
I want to check the error code of such an error.

as one of the guys suggested I can look into the object using Marshal
and I noticed that the error contains a very elaborated, like:
{"Severity":"ERROR","Code":"23505","Message":"duplicate key value violates 
unique constraint \"treatment_pk\"","Detail":"Key (customer_id, 
patient_ttz, therapist_id, appointment_timestamp)=(1, 060525649, 160, 
2022-10-20 10:30:00) already 
exists.","Hint":"","Position":"","InternalPosition":"","InternalQuery":"","Where":"","Schema":"public","Table":"treatment","Column":"","DataTypeName":"","Constraint":"treatment_pk","File":"nbtinsert.c","Line":"434","Routine":"_bt_check_unique"}

Trying to get the same result using straight forward approach like:
fmt.Printf("%+v\n", err) gives me a much simpler object display.

How can I get the "smart" content of the error object like the "Code" 
member?

Sorry to ask such a trivial question. Unfortunately for my, I was unable to 
find an answer yet.

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/aeda952a-c18f-4aa2-8aa9-9a8caf72cfbfn%40googlegroups.com.

[go-nuts] Re: cgo: how to pass an entropy source from golang to C?

[David Stainton]

I think the cleanest way to solve this problem is to use the go-pointers 
library and pass in the opaque pointer from the application through to the 
go callback.

Here's a blog post I found detailing how this is done:
https://eli.thegreenplace.net/2019/passing-callbacks-and-pointers-to-cgo/



On Tuesday, October 18, 2022 at 9:50:21 PM UTC-4 David Stainton wrote:

>
> Okay here I've tried a similar solution to the go-pointers library... but 
> i had to change it a bit to fit how the C library uses the context pointer:
>
> https://git.xx.network/elixxir/ctidh_cgo/-/commit/8f02611b943c269eab5b6e888958e4d41d72cd51
>
> It builds and runs... and then panics on the "rng is nil"... not sure why. 
> So I'm going to try another solution where I change the C api slightly.
>
> I'm convinced there are many possible solutions to this and picking one is 
> a matter of deciding among a few tradeoffs.
>
>
> On Tuesday, October 18, 2022 at 6:33:11 PM UTC-4 David Stainton wrote:
>
>> Greetings cgo experts, perhaps this post might also be of some interest 
>> to cryptography people as well.
>>
>> What's the best way for a C cryptography library to receive entropy from 
>> golang?
>>
>> There exists a C cryptography library (CTIDH, it's a PQ NIKE)... I am 
>> collaborating with C programmers who are adding features to it. I maintain 
>> cgo bindings for this library. Thus far the cgo is straight forward and it 
>> works. However the C programmers recently added a constructor for private 
>> keys which takes a function pointer as an argument:
>>
>> https://codeberg.org/io/highctidh/src/branch/main/csidh.h#L50
>>
>> /*
>>  * generate a new private key using rng_callback and write the result to 
>> (priv).
>>  * (priv) is passed as (context) to the rng_callback.
>>  */
>> void csidh_private_withrng(private_key *priv, ctidh_fillrandom 
>> rng_callback);
>>
>> I did get this to work with an ugly hack where the golang constructor 
>> takes an io.Reader interface object as an argument and sets an unexported 
>> module scoped global variable to the rng/io.Reader object, guarded by a 
>> mutex, gross:
>>
>>
>> https://git.xx.network/elixxir/ctidh_cgo/-/commit/2e7fb078722decb07ab8da7fb59c8ec46fb32fd1
>>
>> But that's a really ugly hack and if called by multiple threads would 
>> result in the rng getting overwritten... which in most cases is probably 
>> fine for that to happen but seems like a bad design.
>>
>>
>>
>>
>>

-- 
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/a8b5fa3e-3ff0-45f1-8864-c169d6cafa23n%40googlegroups.com.

[go-nuts] Re: cgo: how to pass an entropy source from golang to C?

[David Stainton]

Okay here I've tried a similar solution to the go-pointers library... but i 
had to change it a bit to fit how the C library uses the context pointer:
https://git.xx.network/elixxir/ctidh_cgo/-/commit/8f02611b943c269eab5b6e888958e4d41d72cd51

It builds and runs... and then panics on the "rng is nil"... not sure why. 
So I'm going to try another solution where I change the C api slightly.

I'm convinced there are many possible solutions to this and picking one is 
a matter of deciding among a few tradeoffs.


On Tuesday, October 18, 2022 at 6:33:11 PM UTC-4 David Stainton wrote:

> Greetings cgo experts, perhaps this post might also be of some interest to 
> cryptography people as well.
>
> What's the best way for a C cryptography library to receive entropy from 
> golang?
>
> There exists a C cryptography library (CTIDH, it's a PQ NIKE)... I am 
> collaborating with C programmers who are adding features to it. I maintain 
> cgo bindings for this library. Thus far the cgo is straight forward and it 
> works. However the C programmers recently added a constructor for private 
> keys which takes a function pointer as an argument:
>
> https://codeberg.org/io/highctidh/src/branch/main/csidh.h#L50
>
> /*
>  * generate a new private key using rng_callback and write the result to 
> (priv).
>  * (priv) is passed as (context) to the rng_callback.
>  */
> void csidh_private_withrng(private_key *priv, ctidh_fillrandom 
> rng_callback);
>
> I did get this to work with an ugly hack where the golang constructor 
> takes an io.Reader interface object as an argument and sets an unexported 
> module scoped global variable to the rng/io.Reader object, guarded by a 
> mutex, gross:
>
>
> https://git.xx.network/elixxir/ctidh_cgo/-/commit/2e7fb078722decb07ab8da7fb59c8ec46fb32fd1
>
> But that's a really ugly hack and if called by multiple threads would 
> result in the rng getting overwritten... which in most cases is probably 
> fine for that to happen but seems like a bad design.
>
>
>
>
>

-- 
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/cfcb3675-eb9a-46b6-85a8-ceaa1329c185n%40googlegroups.com.

[go-nuts] cgo: how to pass an entropy source from golang to C?

[David Stainton]

Greetings cgo experts, perhaps this post might also be of some interest to 
cryptography people as well.

What's the best way for a C cryptography library to receive entropy from 
golang?

There exists a C cryptography library (CTIDH, it's a PQ NIKE)... I am 
collaborating with C programmers who are adding features to it. I maintain 
cgo bindings for this library. Thus far the cgo is straight forward and it 
works. However the C programmers recently added a constructor for private 
keys which takes a function pointer as an argument:

https://codeberg.org/io/highctidh/src/branch/main/csidh.h#L50

/*
 * generate a new private key using rng_callback and write the result to 
(priv).
 * (priv) is passed as (context) to the rng_callback.
 */
void csidh_private_withrng(private_key *priv, ctidh_fillrandom 
rng_callback);

I did get this to work with an ugly hack where the golang constructor takes 
an io.Reader interface object as an argument and sets an unexported module 
scoped global variable to the rng/io.Reader object, guarded by a mutex, 
gross:

https://git.xx.network/elixxir/ctidh_cgo/-/commit/2e7fb078722decb07ab8da7fb59c8ec46fb32fd1

But that's a really ugly hack and if called by multiple threads would 
result in the rng getting overwritten... which in most cases is probably 
fine for that to happen but seems like a bad design.




-- 
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/4ead4877-4225-4131-b304-82a331ddc1fan%40googlegroups.com.

Re: [go-nuts] Re: Go implementation of CLP

[david lion]

It would be awesome to help SeaweedFS, so I'm eager to hear more about your 
ideas to try and understand anything we can do.

Sorry if some of my questions are naive. At a high level I'm trying to 
better understand two topics:
1. the use cases (or features) we/CLP can help with
2. the technical aspects/limitations that make a pure-go implementation 
necessary/beneficial

I saw that SeaweedFS currently can automatically compresses certain file 
types with Gzip (very cool btw).
I can imagine that augmenting this feature with CLP for log file types 
could be beneficial.
Are these the log files you're referring to? Does SeaweedFS itself also 
produce log files that can benefit from CLP? Perhaps CLP could help with 
both cases?

As I imagine packaging the current form of CLP with SeaweedFS is awkward, 
is packaging a main reason for a pure-go implementation?
Would a library with programmatic API be favourable for integration rather 
than calling out to another tool/executable (as required in CLP's current 
form)?
Would a go package using cgo (to reuse some existing cpp code) be desirable 
or is there a requirement for strictly go code?

-david

On Sunday, 2 October 2022 at 22:36:38 UTC-4 ChrisLu wrote:

> Thanks! CLP is great! 
>
> I am working on a distributed file system, SeaweedFS, 
> https://github.com/seaweedfs/seaweedfs
> I am interested in a pure-go implementation to store the log files more 
> efficiently.
>
> Chris
>
> On Sun, Oct 2, 2022 at 6:45 PM david lion  wrote:
>
>> Hi Chris,
>>
>> I'm one of the CLP developers. We'd be interested in hearing your use 
>> case and any features you'd like implemented in CLP.
>> As for a Go implementation, are you asking about bindings to directly 
>> call CLP functionality from a Go program or are you interested in a 
>> complete re-write in Go?
>>
>> -david
>>
>> On Friday, 30 September 2022 at 03:58:44 UTC-4 ChrisLu wrote:
>>
>>> Seems there are no Go implementation for Compressed Log Processor (CLP) 
>>> yet? 
>>>
>>> CLP is a tool capable of losslessly compressing text logs and searching 
>>> the compressed logs without decompression.
>>>
>>> https://github.com/y-scope/clp
>>>
>>> Chris
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/XeDIZfTMlX8/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/0c57905a-1096-4688-b268-93742c48316fn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/0c57905a-1096-4688-b268-93742c48316fn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/300d1206-04be-4d82-83b9-3ced848a39dbn%40googlegroups.com.

[go-nuts] Re: Go implementation of CLP

[david lion]

Hi Chris,

I'm one of the CLP developers. We'd be interested in hearing your use case 
and any features you'd like implemented in CLP.
As for a Go implementation, are you asking about bindings to directly call 
CLP functionality from a Go program or are you interested in a complete 
re-write in Go?

-david

On Friday, 30 September 2022 at 03:58:44 UTC-4 ChrisLu wrote:

> Seems there are no Go implementation for Compressed Log Processor (CLP) 
> yet? 
>
> CLP is a tool capable of losslessly compressing text logs and searching 
> the compressed logs without decompression.
>
> https://github.com/y-scope/clp
>
> Chris
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0c57905a-1096-4688-b268-93742c48316fn%40googlegroups.com.

Re: [go-nuts] google code style is the same as gofmt in go codes?

[David Finkel]

On Tue, Sep 13, 2022 at 5:39 PM Axel Wagner 
wrote:

>
>
> On Tue, Sep 13, 2022 at 10:46 PM David Finkel 
> wrote:
>
>> On Tue, Sep 13, 2022 at 3:55 PM Moein Halvaei 
>> wrote:
>>
>>> When I read codes from https://cs.opensource.google/go, indents are 2
>>> spaces and when using gofmt indents are 2 tabs. Why?
>>>
>> Google's Codesearch defaults to matching Google's C++ style guide rather
>> than Go's recommended style:
>> https://google.github.io/styleguide/cppguide.html#Spaces_vs._Tabs
>> To be clear: gofmt uses an 8-spaces per tab, not two tabs.
>>
>
> gofmt doesn't determine how many spaces are tab stops aligned to at all.
> That's a property of your editor, IDE or code browser and usually
> configurable. That's part of the appeal of using tabs for indentation and
> why spaces are better for alignment.
>
Well, that's partially true.
There are a few places where gofmt aligns tokens after indentation where
the alignment doesn't quite work out correctly if the tab-stop interval
isn't exactly 8 characters.
The `go/printer` package's Config includes a Tabwidth
<https://pkg.go.dev/go/printer@go1.19.1#Config.Tabwidth> field for a reason
(it's actually passed to a
<https://cs.opensource.google/go/go/+/refs/tags/go1.19.1:src/go/printer/printer.go;l=1391;drc=54182ff54a687272dd7632c3a963e036ce03cb7c>
TabWriter <https://pkg.go.dev/text/tabwriter#Writer> to do the alignment).

(I didn't realize before that the go/printer package actually underlies the
implementation of go/format and cmd/gofmt -- I had assumed that it was a
reimplementation like go/ast vs the compiler-internal ast)

>
>
>> --
>>> 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/3b43a2be-8001-4f53-a952-417b6a909bd9n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/3b43a2be-8001-4f53-a952-417b6a909bd9n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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/CANrC0BgCHM_m2nkAjkqnLDP02-FfYFtOyRv9SW8SAup4NHp1UA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CANrC0BgCHM_m2nkAjkqnLDP02-FfYFtOyRv9SW8SAup4NHp1UA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CANrC0BjJTwmM9QKL5vKCYCd6o8dwd%2BKSG6OyMJ3brwHZNu0tYw%40mail.gmail.com.

Re: [go-nuts] google code style is the same as gofmt in go codes?

[David Finkel]

On Tue, Sep 13, 2022 at 3:55 PM Moein Halvaei  wrote:

> When I read codes from https://cs.opensource.google/go, indents are 2
> spaces and when using gofmt indents are 2 tabs. Why?
>
Google's Codesearch defaults to matching Google's C++ style guide rather
than Go's recommended style:
https://google.github.io/styleguide/cppguide.html#Spaces_vs._Tabs
To be clear: gofmt uses an 8-spaces per tab, not two tabs.

> --
> 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/3b43a2be-8001-4f53-a952-417b6a909bd9n%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/CANrC0BgCHM_m2nkAjkqnLDP02-FfYFtOyRv9SW8SAup4NHp1UA%40mail.gmail.com.

Re: [go-nuts] Any package implementing FIFO mutex?

[David Finkel]

Not a drop-in replacement, but there is net/textproto.Pipeline
. (intended for sequencing
text-based network protocols going over a socket, but it's not too far off)

You'd call `Next()` to grab the sequence-handle and then
call `p.StartRequest(id)` to grab the lock. Unlocking would be
`p.EndRequest(id)`.
I think you can ignore the response-side for this use-case, but I'm not
certain.

On Fri, Sep 9, 2022 at 3:12 PM ChrisLu  wrote:

> "sync.Mutex" is not FIFO. Has any package implemented a dropping for FIFO
> mutex?
>
> One similar solution is to use buffered channel, but it is limited by the
> buffer size, and requires non-trivial re-architecturing.
>
> Chris
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/f4772670-65d8-4b31-a71a-d01ad20214ebn%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/CANrC0BhtxnmU%2B71h_GCph50fCBo5GxCiAJSvrt07JjcFiSMiSw%40mail.gmail.com.

Re: [go-nuts] cgo binding copies data twice, necessary?

[David Stainton]

Hi! Yes that works perfectly. I've added the bounds checking.

Thanks and cheers!

Sincerely,

David

On Tuesday, August 23, 2022 at 3:51:39 AM UTC-4 progl...@gmail.com wrote:

> Assuming that `p.privateKey = *((*C.private_key)(key))` is making a full 
> copy, not shallow. I think you could avoid using `C.CBytes`.
>
> You can get the address of the start of the backing array via [0] as 
> per https://pkg.go.dev/cmd/cgo
>
> So maybe something like this:
> p.privateKey = *((*C.private_key)(unsafe.Pointer([0])))
>
> The code doesn't seem that safe though. There should be something that 
> actually checks that the byte slice is the correct size.
>
> On Tue, 23 Aug 2022 at 00:41, David Stainton  wrote:
>
>> I recently wrote cgo bindings to the CTIDH C library (a bleeding edge 
>> post quantum non-interactive key exchange) copies the data twice. First in 
>> the call to C.CBytes and then again in the assignment to p.privateKey via 
>> that pointer dereference.
>>
>> The performance hit for the twice copy is not really a problem. I'm just 
>> curious, is there's a more proper way to write this that avoids the twice 
>> copy?
>>
>>
>> // FromBytes loads a PrivateKey from the given byte slice.
>> func (p *PrivateKey) FromBytes(data []byte) {
>>key := C.CBytes(data)
>>defer C.free(key)
>>p.privateKey = *((*C.private_key)(key))
>> }
>>
>> https://git.xx.network/elixxir/ctidh_cgo/-/blob/master/binding.go#L49-54
>>
>>
>> Sincerely,
>> David
>>
>> -- 
>> 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/3b8a9098-aabb-4b53-933e-b4e4b6e21cdcn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/3b8a9098-aabb-4b53-933e-b4e4b6e21cdcn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/a30ff3b9-5e61-42a7-aaee-6f7f04b08168n%40googlegroups.com.

[go-nuts] cgo binding copies data twice, necessary?

[David Stainton]

I recently wrote cgo bindings to the CTIDH C library (a bleeding edge post 
quantum non-interactive key exchange) copies the data twice. First in the 
call to C.CBytes and then again in the assignment to p.privateKey via that 
pointer dereference.

The performance hit for the twice copy is not really a problem. I'm just 
curious, is there's a more proper way to write this that avoids the twice 
copy?


// FromBytes loads a PrivateKey from the given byte slice.
func (p *PrivateKey) FromBytes(data []byte) {
   key := C.CBytes(data)
   defer C.free(key)
   p.privateKey = *((*C.private_key)(key))
}

https://git.xx.network/elixxir/ctidh_cgo/-/blob/master/binding.go#L49-54


Sincerely,
David

-- 
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/3b8a9098-aabb-4b53-933e-b4e4b6e21cdcn%40googlegroups.com.

Re: [go-nuts] Type switch on generic parameter

[David Finkel]

On Thu, Aug 11, 2022 at 7:40 PM 'Matt Rosencrantz' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I'd really love to be able to do:
>
> type allowedTypes{
>   int64|float64|string
> }
>
> func Foo[T allowedTypes](arg T) {
> switch t := arg {
>case int64:
>// something
>case string:
>   // something completely different
>}
> }
>
>
As a way of having the type checker disallow other types from being passed
> so I don't have to return an error for incorrect types.  I guess this would
> be the same as asking for typesets to be allowed in normal interfaces like:
>
> func Foo(arg allowedTypes) {...}
>
> Is there another way to achieve this? Is there a reason it is not possible?
>

The type-parameters proposal discusses this a little.
You can cast your arg to an interface-type before type-asserting.
https://go.googlesource.com/proposal/+/HEAD/design/43651-type-parameters.md#identifying-the-matched-predeclared-type
Note that the design uses the interface{} syntax, while you can now use
"any" when converting to an interface.

Worth noting: you'll still have a runtime cost to the type-switch.


> Thanks!
> Matt
>
>
>
> --
> 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/870bc9bd-2fcf-4598-9287-2da7adbc524an%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/CANrC0Bh_bAL%2B_NH5YA1tvM8s4bDOJ3ug2veFOd3q2JjyKaLGdQ%40mail.gmail.com.

[go-nuts] Triggering go:generate via go build/install?

['David Vennik' via golang-nuts]

One of the big advantages of many other build systems and for which reason 
many Go projects use Makefiles is that running generators is not automated.

As I see it, the only thing required to make it automatic is annotation to 
make note of the sources that generators build off and trigger rerunning it 
before the execution of the compilation.

All that would require is some way to tag files such that if the files 
hashes change the generator should be rerun. I probably am not listing all 
the ways that this could be done automatically. I mean, go:generate lines 
always include filesystem references, either folders or specific files, 
these could be automatically checksummed in go.sum to determine when to 
automatically run them.

As I see it, this lack of automatic code generation and the poor 
performance of the Go FFI, Cgo, are the two biggest factors that lead to 
projects drifting away from Go once someone decides to start putting 
foreign code into the mix that they want binary coupling. I think that a 
standardised run control system for child processes so foreign language 
binaries can interface with minimal work would also go some way to fix this 
problem since it isolates the runtimes completely, and in many cases only 
introduces a small latency cost.

-- 
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/fa082a04-8531-4198-9938-ede40959e903n%40googlegroups.com.

Re: [go-nuts] GO program's memory footprint is confusing

[David Finkel]

Looking at proc-10451, I see that there are two mappings with anonymous
huge pages in that smaps output, and none on the other.
Does one machine have transparent hugepages enabled, and the other not?
You can check whether they're enabled on that system by looking
at /sys/kernel/mm/transparent_hugepage/enabled.


Here are the relevant smaps sections:

c0-c00040 rw-p  00:00 0
Size:   4096 kB
KernelPageSize:4 kB
MMUPageSize:   4 kB
Rss:2048 kB
Pss:2048 kB
Shared_Clean:  0 kB
Shared_Dirty:  0 kB
Private_Clean: 0 kB
Private_Dirty:  2048 kB
Referenced: 2048 kB
Anonymous:  2048 kB
LazyFree:  0 kB
AnonHugePages:  2048 kB
ShmemPmdMapped:0 kB
Shared_Hugetlb:0 kB
Private_Hugetlb:   0 kB
Swap:  0 kB
SwapPss:   0 kB
Locked:0 kB
VmFlags: rd wr mr mw me ac sd

7f716a5e2000-7f716c953000 rw-p  00:00 0
Size:  36292 kB
KernelPageSize:4 kB
MMUPageSize:   4 kB
Rss:2092 kB
Pss:2092 kB
Shared_Clean:  0 kB
Shared_Dirty:  0 kB
Private_Clean: 0 kB
Private_Dirty:  2092 kB
Referenced: 2092 kB
Anonymous:  2092 kB
LazyFree:  0 kB
AnonHugePages:  2048 kB
ShmemPmdMapped:0 kB
Shared_Hugetlb:0 kB
Private_Hugetlb:   0 kB
Swap:  0 kB
SwapPss:   0 kB
Locked:0 kB
VmFlags: rd wr mr mw me ac sd


On Fri, Apr 29, 2022 at 12:18 PM garenchan  wrote:

> *What version of Go are you using (go version)?*
>
> $ go version
> go version go1.17.6 linux/amd64
>
> *Does this issue reproduce with the latest release?*
>
> uncertain
>
> *What operating system and processor architecture are you using (go env)?*
>
> $ go env
> GO111MODULE="on"
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="/root/.cache/go-build"
> GOENV="/root/.config/go/env"
> GOEXE=""
> GOEXPERIMENT=""
> GOFLAGS=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOINSECURE=""
> GOMODCACHE="/root/go/pkg/mod"
> GONOPROXY=""
> GONOSUMDB=""
> GOOS="linux"
> GOPATH="/root/go"
> GOPRIVATE=""
> GOPROXY=""
> GOROOT="/home/go"
> GOSUMDB="off"
> GOTMPDIR=""
> GOTOOLDIR="/home/go/pkg/tool/linux_amd64"
> GOVCS=""
> GOVERSION="go1.17.6"
> GCCGO="gccgo"
> AR="ar"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> GOMOD="/home/demo/go.mod"
> 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 -fmessage-length=0
> -fdebug-prefix-map=/tmp/go-build4023324410=/tmp/go-build
> -gno-record-gcc-switches"
>
> *What did you do?*
>
> I encountered a memory problem with the GO program, see here for details.(
> https://stackoverflow.com/questions/71994609/memory-footprint-of-the-same-program-varies-greatly-in-two-similar-environments
> )
>
> In order to simplify the analysis, I wrote a simple program to test.
>
> ```go
> package main
>
> import (
> "time"
> )
>
> func main() {
> time.Sleep(60*time.Second)
> }
> ```
>
>
>- I compiled it into binary file on a linux host `host1` with kernel
>4.18. Then I run it on `host1` and the process takes up close to 5MB RSS.
>- I then copy the binary file to another host `host2` with kernel
>4.18. I also ran it on `host2`, but this time the process took up less than
>1MB RSS.
>- I repeated the test many times and observed the same thing.
>
>
> ```
> $ uname -a
> Linux host1 4.18.0 #1 SMP Wed Nov 10 20:46:19 CST 2021 x86_64 x86_64
> x86_64 GNU/Linux
>
> $ uname -a
> Linux host2 4.18.0 #1 SMP Fri May 8 10:59:10 UTC 2021 x86_64 x86_64 x86_64
> GNU/Linux
> ```
>
> Why is memory footprint of the same program in similar environments so
> different? What factors might be contributing to this problem?
>
> *What did you expect to see?*
>
> I would expect to see the memory footprint of the same program in similar
> environments be close. I look forward to your answers. Thank you very much.
>
> --
> 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/daba9d60-7c45-45f3-83c8-afc2471841c6n%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 

Re: [go-nuts] Add comparisons to all types

[David Arroyo]

On Mon, May 2, 2022, at 22:43, will@gmail.com wrote:
>- Functions: Compare the corresponding memory addresses. The time 
>complexity is constant.

How would this apply to inlined functions? supporting equality would 
essentially force the compiler to keep a the function in the output binary even 
if it's inlined everywhere it's called, just for comparisons. It would also 
complicate 

Here's another example:

type worker struct { ... }
func shutDown() { ... }

func (w *worker) run(orders <-chan func()) {
for f := range orders {
if(f == shutDown) {
log.Printf("got a shutdown command")
w.Cleanup()
}
f()
}
}

currently, Go programs run on a single computer. What if a Go runtime was built 
that ran Go programs across many computers? Or, put another way, what if a 
system architecture emerged where the instruction access time varied so 
drastically across CPU cores that it made sense to duplicate functions across 
cores' fast memory regions, so that the receive operation in the above example 
actually received a duplicate copy of a function? I will admit that closures 
with mutable data segments already complicate such an optimization, but 
function equality would thwart such an optimization altogether.

David

-- 
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/f566007f-aa47-4aaf-bc9e-a0fa9dab1e62%40www.fastmail.com.

Re: [go-nuts] Advice for closed network - problem with go mod

[David Arsenault]

Sean. Brilliant. I don't grasp how I missed the file:// setting. Works 
beautifully and I am a grateful Gopher. THANK YOU.

On Monday, April 25, 2022 at 5:15:33 PM UTC-4 se...@liao.dev wrote:

> See https://go.dev/ref/mod#environment-variables
>
> GOPROXY=file://$(go env GOMODCACHE)/cache/download
>
> - sean
>
>
> On Mon, Apr 25, 2022 at 10:08 PM David Arsenault  
> wrote:
>
>> Hello. I was hoping to get some smart advice on a problem using go on a 
>> closed network. 
>>
>> Summary:
>> - closed network, no outside access (painful, I know)
>> - moved all needed packages to ~/go/pkg...
>> - using go modules
>>
>> Problem:
>> go mod insists on using the network (can't). When I set GOPROXY=off go 
>> mod tidy yells then quits:
>>
>> github.com/Jeffail/gabs/v2: cannot find module providing package 
>> github.com/Jeffail/gabs/v2: module lookup disabled by GOPROXY=off
>>
>> I've tried using replace in go.mod. Same failures. If GOPROXY=off, above 
>> error. If GOPROXY is set to default values it fails on network access.
>>
>> It would be fantastic if there were a way to use go mod and have it look 
>> locally first before trying the network. I don't see a way to do that in 
>> the docs. I even tied -pkgdir dir from the go build docs and that fails 
>> with network access.
>>
>> Is there a potential that my go install is somehow broken? 
>>
>> I suppose I could vendor everything but it would be better if the tool 
>> would find the packages already copied to the closed network.
>>
>> Pulling my hair out. Thanks in advance for your advice Gophers!   
>>
>> David
>>
>> -- 
>> 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/4a400763-dddb-46d7-abf4-2beb711e1287n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/4a400763-dddb-46d7-abf4-2beb711e1287n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/9f182e2e-87f7-4ee3-8cd2-fd45424d8644n%40googlegroups.com.

[go-nuts] Advice for closed network - problem with go mod

[David Arsenault]

Hello. I was hoping to get some smart advice on a problem using go on a 
closed network. 

Summary:
- closed network, no outside access (painful, I know)
- moved all needed packages to ~/go/pkg...
- using go modules

Problem:
go mod insists on using the network (can't). When I set GOPROXY=off go mod 
tidy yells then quits:

github.com/Jeffail/gabs/v2: cannot find module providing package 
github.com/Jeffail/gabs/v2: module lookup disabled by GOPROXY=off

I've tried using replace in go.mod. Same failures. If GOPROXY=off, above 
error. If GOPROXY is set to default values it fails on network access.

It would be fantastic if there were a way to use go mod and have it look 
locally first before trying the network. I don't see a way to do that in 
the docs. I even tied -pkgdir dir from the go build docs and that fails 
with network access.

Is there a potential that my go install is somehow broken? 

I suppose I could vendor everything but it would be better if the tool 
would find the packages already copied to the closed network.

Pulling my hair out. Thanks in advance for your advice Gophers!   

David

-- 
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/4a400763-dddb-46d7-abf4-2beb711e1287n%40googlegroups.com.

Re: [go-nuts] Re: New edition of the Go Programming Language comming soon ?

[David Karr]

There is nothing new here. Every programming language, framework, and tool
has had the same problem.  Quality documentation and training is often the
hardest thing to produce, and is often deemphasized in budgets.  It's also
part of the last 10% of doing something that usually takes 90% of the time.

On Mon, Mar 14, 2022 at 9:58 PM Rob Muhlestein  wrote:

> The essential issue is that there are a number of resources for people
> "with prior programming experience" and literally none for people learning
> Go as a first language. I find this to be very unfortunate because so much
> of Go promotes solid programming practices that could significantly impact
> beginners for the rest of their coding lives (goroutines instead of
> promises, for example). Instead, the community seems content with simply
> suggesting beginners "learn another language first" and I've accepted that.
> I just find it a real loss of an excellent opportunity.
>
> The rest of this is just me blabbing on about helping beginners. 
>
> And I'm sorry, that book is anything but clear. In my experience, the
> people who say such things also say that K C is "clear." It's a matter of
> opinion and audience, and if you are a Ph.D in computer science with C
> coding under your belt, hell yeah, it's *very* clear. I just work with
> beginners with no CS experience a lot and they balk at the irrelevant
> examples, unnecessary bombastic voice, and excessive assumptions. I'm
> sincerely glad some do find it valuable.
>
> By the way, why doesn't our community promote more top-of-the-line, free
> resources over paid books that become immediately out of date? With all the
> money being dumped into "universities" and "free training" of late from
> different corporations facing the doubt of good IT talent I want to believe
> a dedicated team focused specifically on helping beginners adopt Go is a
> possibility --- especially given the critical dependency on Go in all of
> cloud native computing. Being able to read Go source (minimally) should be
> mandatory learning for any infrastructure engineer these days. I've solved
> so many problems simply from reading the K8S or Helm source rather than the
> docs.
>
> I get the impression so many are so busy doing amazing things *with* Go
> that there is very little energy left to do things to help others start,
> and by others I don't mean those paying for corporate training. I mean
> those capable of learning but with limited means; I mean the AP CS programs
> that are still mandating mastering of single OOP inheritance that
> completely neglect concurrent programming practices; I mean self-taught
> upskillers learning to write their own Kubernetes operators. Go could
> easily displace Java as the best AP CS language if more attention were
> given to these considerations.
>
> The Tour of Go is only about 60% finished according to the project
> milestones in the source of the project. And who thought throwing bitwise
> operators in the first chapter (or so) was a good idea?
>
> It just seems like people are content letting beginners fend for
> themselves, which is fine for most, but not for the vast majority of people
> for whom Go is supposedly created. This is the reason I regularly receive
> feedback about Go from the many I've helped who say, "Go just isn't
> beginner friendly" and I'm tired of them saying that "Rust is more
> welcoming" (which is just so untrue).
>
> I know I'm droning on, but someone has to bring this up. Go *is* for
> beginners. We just need help convince people, and frankly that starts with
> being able to make a simple, solid book/resource recommendation for
> beginners. There's just nothing out there. I've read 'em all. There are
> literally no books that cover even 1.17 for beginners. (Modules were one of
> the worst things to happen to beginners and we are finally getting on with
> a simpler future.) With Go 1.18 we have a real opportunity to correct this.
>
> For the record, I'm slowly putting together enough material to
> crowd-source a beginner Go 1.18 book and have probably a few dozen people
> interested in helping, but like so many others, I have other stuff I'm
> first required to focus on. Look forward to anything I can do to help.
>
> Thank you.
>
> ---
> Rob Muhlestein
> r...@rwx.gg
> https://twitch.tv/rwxrob
>
> --- Original Message ---
>
> On Monday, March 14th, 2022 at 1:06 PM, Steve Mynott <
> steve.myn...@gmail.com> wrote:
>
> > My experience with this book has been different. I thought it was
> >
> > superb -- a masterpiece of clarity.
> >
> > I don't think it's intended for absolute beginners to programming but
> >
> > it's great for people with prior programming experience.
> >
> > It seems to me unlikely there isn't a suitable absolute beginners book
> >
> > available from publishers such as Manning, O'Reilly and No Starch
> >
> > Press.
> >
> > S
> >
> > On Mon, 14 Mar 2022 at 16:09, Rob Muhlestein r...@rwx.gg wrote:
> >
> > > As an educator and mentor I've 

[go-nuts] BPF target

['David Vennik' via golang-nuts]

With the Solana project running with the old and perfectly adequate BPF 
bytecode and execution engines already inside the linux kernel, it seems 
that this might be a good target to add to Go's existing targets. 

I mean, yes, I am aware of the severe limitations, no loops, etc, but to be 
able to deploy Solana apps end to end with a Go backed frontend and Go 
language for the programs... 

I'm not expecting a strong enthusiastic response about the subject, of 
course, but I think there could be a big bonus for Go adoption if it became 
an option for this very interesting, very fast blockchain platform.

It does not have to even permit most of the basics, maps, slices, they just 
simply don't need to be used. It might also go along with efforts  such as 
tinygo, rather than on the mainline project. 

As I spent a long time developing my skills with Go towards "Layer 1" 
blockchain systems, including also some time inside a Geth fork, I feel 
like Go is slipping a little with keeping relevant to this very active area 
of software development.

-- 
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/d069d525-c673-484c-b00e-d12de77ab14dn%40googlegroups.com.

Re: [go-nuts] How to debug "Not a valid zip file" from zip.OpenReader

[David Karr]

Ok.  I did that. https://github.com/golang/go/issues/51337 .

On Wed, Feb 23, 2022 at 4:20 PM Ian Lance Taylor  wrote:

> On Wed, Feb 23, 2022 at 1:46 PM David Karr 
> wrote:
> >
> > A while ago, I wrote a small Go app that reads things from zip files.  I
> tested it with various zip files (usually Java jar files), and it has
> always worked perfectly fine.
> >
> > Today I'm looking at another jar file.  The Java "jar" command likes it
> perfectly fine. I could list the contents and extract all the files. Java
> had no particular trouble running with the jar file.
> >
> > When I try to call "zip.OpenReader()" on this jar file, it just gives me
> ""zip: not a valid zip file"".  Well, great.
> >
> > I then ran a command to run the same command on every jar file in my
> home directory tree, where there are a couple of thousand from various tool
> distributions.  I counted how many failed with that same error. I found
> just the one I already have.
> >
> > This jar file is a little over 12mb.  Several of the jar files that
> don't fail are quite a bit larger than this. Most of the ones that don't
> fail are smaller than this. The permissions on this jar are the same as the
> others.
> >
> > I then tried passing this jar file to "unzip". It was able to unzip it,
> but it did print this:
> >
> > warning []:  3624 extra bytes at beginning or within
> zipfile
> >   (attempting to process anyway)
> >
> > I tried this on some of the working jar files, and it didn't print this
> warning.
> >
> > So, it appears that if anything, this jar file is "nonstandard", but
> both unzip and jar have no problem with it, and jar didn't even say there
> was an issue with it.  The zip package, however, bombs on this with no
> information.
> >
> > I'm going to go to the people who gave me that jar file and ask them how
> they produced it, but I think it's clear it's not fatally broken.
> >
> > I haven't submitted a bug report for this package yet, as I wanted some
> feedback on this first.
>
> The error is zip.ErrFormat.  From a quick look at the sources it can
> be returned if
>
> - a file header does not start with the required signature (0x04034b50)
> - a directory header does not start with the required signature
> (0x02014b50)
> - a directory entry is too short to contain the additional information
> it claims to hold
> - a directory entry fails to contain the additional information it
> claims to hold
> - the directory end signature (0x06054b50) is not found
> - the offset in the directory is invalid (negative or larger than the file
> size)
>
> There is no especially easy way to find out exactly which one is
> happening.  You could add some print statements to
> archive/zip/reader.go to narrow it down.
>
> I'm not sure what to make of the "3624 extra bytes".
>
> Not sure how much this helps.  If you can share the zip file, you
> could open a bug report.
>
> Ian
>

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

[go-nuts] How to debug "Not a valid zip file" from zip.OpenReader

[David Karr]

A while ago, I wrote a small Go app that reads things from zip files.  I 
tested it with various zip files (usually Java jar files), and it has 
always worked perfectly fine.

Today I'm looking at another jar file.  The Java "jar" command likes it 
perfectly fine. I could list the contents and extract all the files. Java 
had no particular trouble running with the jar file.

When I try to call "zip.OpenReader()" on this jar file, it just gives me 
""zip: not a valid zip file"".  Well, great.

I then ran a command to run the same command on every jar file in my home 
directory tree, where there are a couple of thousand from various tool 
distributions.  I counted how many failed with that same error. I found 
just the one I already have.

This jar file is a little over 12mb.  Several of the jar files that don't 
fail are quite a bit larger than this. Most of the ones that don't fail are 
smaller than this. The permissions on this jar are the same as the others.

I then tried passing this jar file to "unzip". It was able to unzip it, but 
it did print this:

warning []:  3624 extra bytes at beginning or within 
zipfile
  (attempting to process anyway)

I tried this on some of the working jar files, and it didn't print this 
warning.

So, it appears that if anything, this jar file is "nonstandard", but both 
unzip and jar have no problem with it, and jar didn't even say there was an 
issue with it.  The zip package, however, bombs on this with no information.

I'm going to go to the people who gave me that jar file and ask them how 
they produced it, but I think it's clear it's not fatally broken.

I haven't submitted a bug report for this package yet, as I wanted some 
feedback on this first.

-- 
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/3a235738-3ce0-4357-8c78-870fc61c8829n%40googlegroups.com.

Re: [go-nuts] Is there a way to specify or use the tmp directory used in testing?

[David Finkel]

On Wed, Feb 23, 2022 at 1:47 PM Gergely Brautigam 
wrote:

> Hi!
>
> The best way to do it is, to have these files in a folder next to the test
> called `testdata` and then when the test starts, simply copy them into a
> temp location. And then make your program work with an environment property
> or setting which can configure the path in which is loads these files from
> and set that environment property for the test to the Temp folder you just
> copied your files to.
>
> And don't forget to defer os.RemoveAll(tmp) :)
>
You don't need this if you use t.TempDir
<https://pkg.go.dev/testing#T.TempDir> to create the tempdir. :)

>
> On Wednesday, 23 February 2022 at 16:30:06 UTC+1 david@gmail.com
> wrote:
>
>> On Wed, Feb 23, 2022 at 8:53 AM Leam Hall  wrote:
>>
>>> My program uses data and template files located relative to the binary.
>>> Since go test creates the binary under test in /tmp/go-build., there
>>> are no data or template files. How do I either specify what directory to
>>> build in so I can create the files, or get the tmp directory name before
>>> the tests are run so I can write files to it?
>>>
>>
>> When go test runs tests, they run with the current working directory
>> inside the package's directory, so relative paths should work.
>>
>> Another option that you might want to consider is using //go:embed
>> directives to embed those files in your binary. (package doc:
>> https://pkg.go.dev/embed)
>> This way you never need to resolve anything relative to the binary again.
>>
>> Note: unless you use mlock(2) embedding in the binary shouldn't bloat
>> memory usage, since the data will only be paged into memory at first-access.
>>
>>>
>>> Thanks!
>>>
>>> Leam
>>>
>>> --
>>> Site Automation Engineer   (reuel.net/resume)
>>> Scribe: The Domici War (domiciwar.net)
>>> General Ne'er-do-well  (github.com/LeamHall)
>>>
>>> --
>>> 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/7d8cf3dc-14ab-315f-ce5a-9e3cca877e17%40gmail.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/8ffeae9e-ce1d-4a7d-af01-b24a1d13c7cdn%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/8ffeae9e-ce1d-4a7d-af01-b24a1d13c7cdn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CANrC0BjvgCD%3D7GrhSsV1xHuZjGj6wHso_-qpCWBRbEj8MW-%3DgA%40mail.gmail.com.

Re: [go-nuts] Is there a way to specify or use the tmp directory used in testing?

[David Finkel]

On Wed, Feb 23, 2022 at 8:53 AM Leam Hall  wrote:

> My program uses data and template files located relative to the binary.
> Since go test creates the binary under test in /tmp/go-build., there
> are no data or template files. How do I either specify what directory to
> build in so I can create the files, or get the tmp directory name before
> the tests are run so I can write files to it?
>

When go test runs tests, they run with the current working directory inside
the package's directory, so relative paths should work.

Another option that you might want to consider is using //go:embed
directives to embed those files in your binary. (package doc:
https://pkg.go.dev/embed)
This way you never need to resolve anything relative to the binary again.

Note: unless you use mlock(2) embedding in the binary shouldn't bloat
memory usage, since the data will only be paged into memory at first-access.

>
> Thanks!
>
> Leam
>
> --
> Site Automation Engineer   (reuel.net/resume)
> Scribe: The Domici War (domiciwar.net)
> General Ne'er-do-well  (github.com/LeamHall)
>
> --
> 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/7d8cf3dc-14ab-315f-ce5a-9e3cca877e17%40gmail.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/CANrC0Bj5UWhsA16_6kK%3D38oROOZ4P24QKEYUP2tTCvYG0bydjQ%40mail.gmail.com.

[go-nuts] Getting "$GOPATH/go.mod exists but should not" when running build in a Docker image

[David Karr]

I had earlier written a note about troubles refactoring my project to have 
a "src" directory, but I've backed off on that for now.  I see that the 
main problem I saw with that hasn't changed when backing out those changes. 
It appears that running this build inside a docker image seems to be 
somehow causing this problem.

In any case, I have a relatively simple go application with main.go, 
go.mod, and go.sum in the root directory, with subdirectories containing 
other source files in packages.

When I just run "go build ..." from the command line in the root directory 
of my project, it works fine and produces a working executable.

However, I'm trying to get this build to work within a published go 
"builder" image, which I will use as the first stage in a multi-stage 
Docker build.

I will first state that this has something to do with GOPATH, and I've gone 
through 
https://www.digitalocean.com/community/tutorials/understanding-the-gopath , 
but I'd have to say that I still don't understand its proper role here.

Not sure what you would want to see first, but here's a plain "ls" of the 
root directory of my project:
-
./ Dockerfilego.mod   JenkinsfileREADME.md
../ .dockerignorego.sum   lib/   
 target/
app/ .git/handlers/  main.gotrustStore/
config/  .gitignoreinclude/   Makefilefuncs/
---

Just running "make build" does this:
-
CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o ../target/dist/linux-amd64
-

Which is fine.

My "dockerbuild" target in the Makefile is this:

dockerbuild:
docker build \
--build-arg host_src_path=. \
--build-arg packages=. \
--build-arg executable_name=appgo \
--build-arg cgo_enabled_01=1 \
--build-arg goos=linux \
--build-arg goarch=amd64 \
-f Dockerfile -t appgo .
---

My Dockerfile, before the start of the second build stage, is this:

FROM .../golang:1.17.6-bullseye as go-builder

ARG packages
ARG executable_name
ARG host_src_path
ARG cgo_enabled_01
ARG goos
ARG goarch

COPY $host_src_path .
RUN env
RUN ls -lt
RUN ls -lt $GOPATH
#RUN go mod download

RUN CGO_ENABLED=$cgo_enabled_01 GOOS=$goos GOARCH=$goarch go build 
-o $executable_name $packages


When I run "make dockerbuild", I see this:
--
Sending build context to Docker daemon  125.8MB
Step 1/19 : FROM .../golang:1.17.6-bullseye as go-builder
 ---> 80d9a75ccb38
Step 2/19 : ARG packages
 ---> Using cache
 ---> d98015e225b1
Step 3/19 : ARG executable_name
 ---> Using cache
 ---> 1d336ac5cf1b
Step 4/19 : ARG host_src_path
 ---> Using cache
 ---> 59595b09a376
Step 5/19 : ARG cgo_enabled_01
 ---> Using cache
 ---> 3c4c08392ede
Step 6/19 : ARG goos
 ---> Using cache
 ---> 6ed0d6881fb4
Step 7/19 : ARG goarch
 ---> Using cache
 ---> 9e4b94e86b09
Step 8/19 : COPY $host_src_path .
 ---> 4727e2fc3e80
Step 9/19 : RUN env
 ---> Running in 8fcedaa86227
HOSTNAME=8fcedaa86227
HOME=/root
packages=.
cgo_enabled_01=1
goarch=amd64
host_src_path=.

PATH=/go/bin:/usr/local/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
goos=linux
GOPATH=/go
executable_name=appgo
PWD=/go
GOLANG_VERSION=1.17.6
Removing intermediate container 8fcedaa86227
 ---> 46e44a5a3539
Step 10/19 : RUN ls -lt
 ---> Running in 75107286d337
total 128
-rw-rw-r-- 1 root root   635 Feb 11 18:37 Dockerfile
-rw-rw-r-- 1 root root   737 Feb 11 18:29 Makefile
-rw-rw-r-- 1 root root   131 Feb 10 18:59 Jenkinsfile
drwxrwxrwx 2 root root  4096 Jan 27 10:09 bin
drwxrwxrwx 2 root root  4096 Jan 27 10:09 src
-rw-rw-r-- 1 root root   967 Jan 13 18:34 main.go
drwxrwxr-x 3 root root  4096 Jan 11 23:46 target
drwxrwxr-x 2 root root  4096 Jan 11 23:46 funcs
drwxrwxr-x 3 root root  4096 Jan 11 21:06 trustStore
-rw-rw-r-- 1 root root  1454 Jan 11 21:06 README.md
drwxrwxr-x 2 root root  4096 Jan 11 21:06 app
drwxrwxr-x 2 root root  4096 Jan 11 21:06 config
-rw-rw-r-- 1 root root   806 Jan 11 21:06 go.mod
-rw-rw-r-- 1 root root 65194 Jan 11 21:06 go.sum
drwxrwxr-x 2 root root  4096 Jan 11 21:06 handlers
drwxrwxr-x 3 root root  4096 Jan 11 21:06 include
drwxrwxr-x 4 root root  4096 Jan 

[go-nuts] Having trouble getting app to build with Docker after moving to a "src" directory

[David Karr]

I had a small go application building successfully.  I had the go.mod and 
main.go in the root directory of the project, and I was building it pretty 
easily with a Makefile, which just did the following:

CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o 
target/dist/linux-amd64

I decided I wanted to move the go source files out of the root dir, so I 
created a "src" directory, then moved "go.*" and my package subdirs to 
"src".  Getting this simple build to work was simple.

I also am constructing a multi-stage Dockerfile, which will be used in the 
CI build. This is a little more complicated, and I'm getting an error on 
the build command that I don't understand.

My Dockerfile looks something like this (... in some places):

--
FROM .../golang:1.17.6-bullseye as go-builder

ARG packages
ARG executable_name
ARG host_src_path
ARG cgo_enabled_01
ARG goos
ARG goarch

COPY $host_src_path .
RUN ls -lt
#RUN go mod download

RUN CGO_ENABLED=$cgo_enabled_01 GOOS=$goos GOARCH=$goarch go build 
-o $executable_name $packages

FROM .../ubuntu-base:20.04

COPY ...
EXPOSE 8080

ENTRYPOINT ...
--

The Docker build looks something like this (... in some places):
-
docker build \
--build-arg host_src_path=src \
--build-arg packages=. \
--build-arg executable_name=... \
--build-arg cgo_enabled_01=1 \
--build-arg goos=linux \
--build-arg goarch=amd64 \
-f Dockerfile -t target/dist/linux/amd64/... .
-

When I run this, I see the following:

Step 10/17 : RUN CGO_ENABLED=$cgo_enabled_01 GOOS=$goos 
GOARCH=$goarch go build -o $executable_name $packages
 ---> Running in 62ef0147061e
$GOPATH/go.mod exists but should not
The command '/bin/sh -c CGO_ENABLED=$cgo_enabled_01 GOOS=$goos 
GOARCH=$goarch go build -o $executable_name $packages' returned a non-zero 
code: 1
make: *** [Makefile:12: dockerbuild] Error 1
---

I googled that error message about go.mod, but I don't understand the 
results, and I don't fully understand how to use GOPATH. I don't remember 
doing anything with it before.

I'm sure I'm operating on some misconceptions, but I'm not sure what I'm 
doing wrong.

-- 
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/484dc24a-18c6-4a7c-84ca-f8acc61c0460n%40googlegroups.com.

[go-nuts] What exactly can be supplied as "packages" on the go build command line?

[David Karr]

When I enter "go help build", the first few lines shows this:

  usage: go build [-o output] [build flags] [packages]

  Build compiles the packages named by the import paths,

The instructions say very little about what can be supplied as "packages". 
It says it can be a list of .go files, and apparently assumes all of the 
supplied files are in a single package , which seems like an odd assumption.

However, I discovered one resource, and from my testing, that just 
supplying "." (period) there also builds the application.

>From what I can see, it appears that the basic help information doesn't 
tell the entire story about what can be supplied there, and exactly how 
those values are used.

What are all the legal variations of what can be supplied there, and what 
are the exact semantics of those values?

-- 
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/a6e92bac-e8d6-4cea-b451-a7a1c14af6c3n%40googlegroups.com.

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[David Finkel]

On Sat, Jan 29, 2022 at 6:21 AM Tim Hardcastle 
wrote:

> Agree with Rudolf on point 2. Long meaningful variable/function names are
> good. Comments become obsolete, they become detached from their code,
> they're only used to explain the name of the variable once and then you're
> left with something than reads
>
> // urn contains the userlist
> fxn := rx (frn)
>
>  Now that editors have autocomplete to make up for my meagre typing speed,
> you bet your ass I'm going to have [eg from current project] a local
> variable called lastTokenWasColon and a method called addWordsToParser.
> Because knowing exactly what they do when I need to modify or debug saves
> me so much time and trouble. (Perhaps this varies from person to person. If
> my memory is poorer than yours, it has more of an upside for me than for
> you.)
>

There's a lot of middle-ground between a three-letter variable or
function-name and encoding the whole doc-comment for a function or variable
in its name.
Humans only have so much working memory, once a name gets long enough we
start dropping parts of the name and it tends to be stuff in the middle
that gets dropped.

If you have a parser type, and a variable with that type, often, it would
be better to have an addWords() method on the parser type. Then if you also
need a special-case addWord() it's easy to tell what's going on.

I try to have meaningful names, but beyond some threshold, but I try to
prevent things from being redundant with the types involved (the entire
function signature and type of the variable).

Also, comments are not about just describing what something is. (those are
the least useful types of comments) They're also quite useful for
describing what's being attempted, what corner-cases are being addressed
and if there's any tricky logic that needs to be handled. Additionally,
IMO, just about any function or method should have a doc-comment explaining
what it expects. (helpers under ~3 lines may be exempt)

>
> And is there a better solution to the problem in point 1 than to break the
> function down into lots of little functions *with meaningful names*? (If
> the names (and pieces) aren't meaningful you've only technically broken it
> down.)
>
> On Friday, January 28, 2022 at 10:12:48 AM UTC-8 Rudolf Martincsek wrote:
>
>> > 2) Long variable names.
>>
>> Where I work (not in Go), writing comments is frowned upon. That includes
>> "docblock" style comments. If a function needs to be documented, it means
>> the implementation is too complex and must be broken apart to reduce
>> cyclomatic or whatever perceived complexity. Also uncle bob told us that
>> functions should never be longer than 2-3 lines of code, so it should be
>> enough to look at the source code to see what it does. That's the general
>> sentiment in my team.
>> Comments are considered sign of "un"clean code.
>>
>> So we use long variable and function names to make the code self
>> documenting. (Hint: it doesn't)
>> Points 3,4,5 have similar roots, because in dynamic languages it was a
>> trend many years ago. (ie: hungarian notation)
>>
>> On Thursday, December 9, 2021 at 2:10:18 PM UTC+2 Amnon wrote:
>>
>>> 1) Long functions that go on forever and contain long lambdas and 8
>>> levels of indentation.
>>>
>>> 2) Long variable names.
>>>
>>> 3) Variable names which include the type of the variable.
>>>
>>> 4) Packages whose name contain the word '/pkg/'
>>>
>>> 5) Repos which contain the prefix go-
>>>
>>> 6) Code where almost every line prefixed by `_, _ =`
>>> and the underscores won't go away when you wipe your screen
>>>
>>>
>>> --
> 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/6a824f2c-d1b6-43f7-8c07-a1e9b8f5376en%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/CANrC0BgMG03iVChUjD7O876H1Yu7r2Vvcwm5TT6zCWYtyVJqWg%40mail.gmail.com.

Re: [go-nuts] Looping and tail-end code

[David Finkel]

On Wed, Jan 12, 2022 at 5:02 AM Tobias Klausmann 
wrote


> So what is the *idiomatic* way of being able to use `continue` (or
> something like it), yet have "always do this" code at the end of the
> loop? As I understand it, `defer` only works for ends of functions, not
> ends of blocks, and label breaks only work for breaks, obviously.
>

I generally pull the bulk of the loop body into another function/method
(usually called tick()) that I call inside the loop just before sleeping.
 (or more typically, a select{} block checking a ticker and a context)

(I like Rob's option, too. -- although that doesn't work with select{}
blocks as well)

-- 
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/CANrC0Bi4k%2BURHVmOsiZkMTp9UR1EGSDO0hvgij20zv1dsrP%2BFg%40mail.gmail.com.

Re: [go-nuts] Re: Alternatives to wrapping errors

[David Finkel]

On Fri, Dec 31, 2021 at 5:12 AM Brian Candler  wrote:

> On Friday, 31 December 2021 at 08:10:49 UTC Henry wrote:
>
>> The purpose of error wrapping is to give contextual information about the
>> error. It is supposed to help you understand and locate the error. For
>> instance, *"invalid filename"* is not particularly useful when compared
>> to *"fail to load customer data: invalid filename"*. Error wrapping is a
>> stack trace in a human-friendly language.
>
>
> I disagree with that explanation, because what you describe can be done
> without wrapping:
> return fmt.Errorf("Failed to load customer data: %v", err)
> or with wrapping:
> return fmt.Errorf("Failed to load customer data: %w", err)
>
> Both provide exactly the same human-friendly trace.  The difference is
> that with the wrapped error, the error value can be destructured to
> retrieve the "cause" error object, and hence to match on that object. It's
> an invitation to your API consumer to couple directly to error types which
> your code doesn't return, but which originate from elsewhere, typically
> system libraries or third-party libraries.
>
> The question then is, under what circumstances is that a good idea?  It
> depends.  Perhaps one example is if your code is using an underlying
> database API, and you are happy to expose raw database-level errors.  That
> allows your own library to wash its hands of responsibility of how to deal
> with these, and let the consumer deal with them if it wants to.  (Was it a
> temporary connection error? Was it a uniqueness constraint violation?  Not
> My Problem™)
>

There's a good argument to be made against wrapping errors at
api-boundaries in some cases. IMO, that's something that's definitely
case-by-case as there are situations where bubbling up the underlying error
is 100% the right thing to do.
e.g. io/fs.FS  implementations are
constrained to returning the io/fs.PathError
 type by the interface documentation in
some cases. However, there are specific underlying sentinel values that
should be bubbled up and accessible.

IMO, within a package (or somewhat intentionally nebulously: "between API
boundaries"), it's generally a good idea to use error wrapping so outer
layers can make the actual wrapping, unwrapping, switching decisions.
By using error-wrapping, you're free to break functions up and add context
as it bubbles up, without losing the ability to switch on the original
error. (or at least use errors.Is or errors.As)

As an example of a the above trade-off, here's an io/fs.FS implementation I
pushed up recently:
https://gitlab.com/dfinkel/go-safefs/-/blob/ca532e3c5c5c/fs_linux.go#L78-105
It's switching on errno values and wrapping specific sentinel errors with
context for the errno values I knew I could see, with specific diagnostics
for those errors.

Worth noting: stack traces rarely have argument values, and don't generally
have other context information, e.g. EMFILE handling specifically checks
the rlimit to get the fd limit value to include in the error message. Stack
traces are nice for the programmer if they've opened the right version of
the code, but useless for everyone else. Errors with context are orders of
magnitude more useful if written correctly. (one of the reasons I don't
like exceptions is that most of the time you just get the stack trace and
original error, which is only barely useful for debugging if you have the
most trivial bugs)

> --
> 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/fa907dec-1dc7-4909-9743-4d91eb146481n%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/CANrC0BgDVcWOxf_hvnPF7yAUoG3JJ16cFHVVhjZpX-bSS8jNCw%40mail.gmail.com.

Re: [go-nuts] grpc and golang struct tags

[David Finkel]

On Sat, Nov 27, 2021 at 10:53 AM Sankar  wrote:

> Hi
>
> I have a database that has a column `2xxCode`. This database is part of a
> legacy system and I cannot make changes to this, as there are multiple
> applications that depend on this, and some of the applications are
> unchangeable.
>
> Now I want to create a new gRPC server in golang that has to interact with
> the data stored in this database.
>
> Since golang variable names cannot begin with a number, I need create a
> `.proto` file which should generate a golang struct member like:
>
> type mystruct {
> TwoxxCode `db:"2xxCode"`
> }
>
> from my .proto file. But I could not find out how to generate a golang
> struct from a .proto file, with adding custom tags to the struct. On
> searching, I found https://github.com/golang/protobuf/issues/52 and the
> second comment on the issue seems very strongly worded as if this would
> never happen in protobuf. Also, the bug seems open for a long time.
>
> How have others solved this problem to add custom tags to proto generated
> golang structs ? Are there any best-known-methods for this ? There were a
> couple of scripts mentioned in the comments, but I am not sure what to
> pick. Any recommendations ?
>
My general recommendation is "don't".
It's quite rare that DBs and RPC interfaces will stay a direct mapping.
Usually one or the other will need to evolve over time, and a bit of
separation is not a bad thing.

Usually, my recommendation is to create "model" structs representing what's
actually in the DB, and then have translation functions to convert to/from
the protobuf forms. (I also recommend having an interface around the DB
implementation itself to make testing and migrations easier)

I'm in the process of moving one of the services I own off gogo protobuf
 (which is quasi-abandoned
 and looking for new ownership
because it needs to be rewritten on top of the new go protobuf api)


> 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/239e2f6a-09f7-4e89-a921-ec3fead637c7n%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/CANrC0BiTG08mpC4qZoj5UcD6N_xU2r3cyctgKXt7Lajs1Sv9Uw%40mail.gmail.com.

Re: [go-nuts] How to vary cgo lib path by os?

[David Karr]

On Saturday, November 27, 2021 at 1:13:12 PM UTC-8 David Karr wrote:

> On Sat, Nov 27, 2021 at 11:57 AM Ian Lance Taylor  
> wrote:
>
>> On Sat, Nov 27, 2021 at 11:01 AM David Karr  
>> wrote:
>> >
>> > I'm aware of the "build constraints" mechanism, which lets individual 
>> files be only compiled on specific oses or architectures.
>> >
>> > I am constructing an app that has a single cgo module, which is the 
>> "meat" of the application (longest module). In my poc, the cgo header 
>> specifies a lib path with "linux" in the path, to point to the linux 
>> libraries. I haven't constructed a Makefile for this yet, but this works 
>> well with vscode and simple testing.
>> >
>> > I now have to consider how to build this on Windows, although the 
>> deployment target for this will be Linux. I have to allow for testing of it 
>> on Windows, if possible. I thought perhaps that I could change the lib path 
>> in the cgo header to reference "${GOOS}" instead, but it doesn't seem to 
>> recognize that.
>> >
>> > It's not reasonable to use build constraints for this, because it seems 
>> like I would have to duplicate the entire module in order to vary the lib 
>> path.  That would be absurd.
>> >
>> > What are reasonable strategies for this, including facilitating testing 
>> of it in vscode on both Linux and Windows?
>>
>> If I'm reading this correctly, you can address this by using
>> GOOS/GOARCH build tags in your #cgo comments.  See, for example,
>> https://go.dev/src/runtime/cgo/cgo.go?#L14.  This is documented at
>> https://pkg.go.dev/cmd/cgo#hdr-Using_cgo_with_the_go_command.
>>
>> Ian
>>
>
> So you're saying I could do this:
>
> // #cgo linux LDFLAGS: -L${SRCDIR}/../lib/linux -llib1 -llib2 -llib3 
> -llib4
> // #cgo windows LDFLAGS: -L${SRCDIR}/../lib/windows -llib1 -llib2 
> -llib3 -llib4
>
> If so, that would be much better than duplicating the entire file. It 
> looks a little odd to duplicate the library list, but if that's the best we 
> can do, I guess that's it.
>
> I'll test this later.
>

Hm, I'm going to guess you're going to tell me that I can't quite do that, 
as I just verified that, unless I'm simply doing it wrong.  I wrote almost 
exactly what I showed there.  I'm having some trouble figuring out how to 
set up the C compiler on Windows, but I have verified with other 
applications that I can cross-compile a build on Linux for Windows, so I 
simply ran this:

GOOS=windows go build -o target/dist/windows-amd64

This fails with:

imports voltagems/voltagefuncs: build constraints exclude all Go files 
in /home/dk068x/git/voltagego/voltagefuncs

Any way to fix this?

-- 
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/3612945d-3a99-4bf8-9ea1-262f4f5fa244n%40googlegroups.com.

Re: [go-nuts] How to vary cgo lib path by os?

[David Karr]

On Sat, Nov 27, 2021 at 11:57 AM Ian Lance Taylor  wrote:

> On Sat, Nov 27, 2021 at 11:01 AM David Karr 
> wrote:
> >
> > I'm aware of the "build constraints" mechanism, which lets individual
> files be only compiled on specific oses or architectures.
> >
> > I am constructing an app that has a single cgo module, which is the
> "meat" of the application (longest module). In my poc, the cgo header
> specifies a lib path with "linux" in the path, to point to the linux
> libraries. I haven't constructed a Makefile for this yet, but this works
> well with vscode and simple testing.
> >
> > I now have to consider how to build this on Windows, although the
> deployment target for this will be Linux. I have to allow for testing of it
> on Windows, if possible. I thought perhaps that I could change the lib path
> in the cgo header to reference "${GOOS}" instead, but it doesn't seem to
> recognize that.
> >
> > It's not reasonable to use build constraints for this, because it seems
> like I would have to duplicate the entire module in order to vary the lib
> path.  That would be absurd.
> >
> > What are reasonable strategies for this, including facilitating testing
> of it in vscode on both Linux and Windows?
>
> If I'm reading this correctly, you can address this by using
> GOOS/GOARCH build tags in your #cgo comments.  See, for example,
> https://go.dev/src/runtime/cgo/cgo.go?#L14.  This is documented at
> https://pkg.go.dev/cmd/cgo#hdr-Using_cgo_with_the_go_command.
>
> Ian
>

So you're saying I could do this:

// #cgo linux LDFLAGS: -L${SRCDIR}/../lib/linux -llib1 -llib2 -llib3
-llib4
// #cgo windows LDFLAGS: -L${SRCDIR}/../lib/windows -llib1 -llib2
-llib3 -llib4

If so, that would be much better than duplicating the entire file. It looks
a little odd to duplicate the library list, but if that's the best we can
do, I guess that's it.

I'll test this later.

-- 
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/CAA5t8VpJmWicztChWPPEQSw1zH3Z68UzNYroQGEs%3DaAG%2BO2Gww%40mail.gmail.com.

[go-nuts] How to vary cgo lib path by os?

[David Karr]

I'm aware of the "build constraints" mechanism, which lets individual files 
be only compiled on specific oses or architectures.

I am constructing an app that has a single cgo module, which is the "meat" 
of the application (longest module). In my poc, the cgo header specifies a 
lib path with "linux" in the path, to point to the linux libraries. I 
haven't constructed a Makefile for this yet, but this works well with 
vscode and simple testing.

I now have to consider how to build this on Windows, although the 
deployment target for this will be Linux. I have to allow for testing of it 
on Windows, if possible. I thought perhaps that I could change the lib path 
in the cgo header to reference "${GOOS}" instead, but it doesn't seem to 
recognize that.

It's not reasonable to use build constraints for this, because it seems 
like I would have to duplicate the entire module in order to vary the lib 
path.  That would be absurd.

What are reasonable strategies for this, including facilitating testing of 
it in vscode on both Linux and Windows?

-- 
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/6d32bce7-b9db-4e08-9494-6cd115fa4f5cn%40googlegroups.com.

Re: [go-nuts] some incorrect code in blog.

[David Karr]

I meant, did you test it with a bad path, and with the defer before the
error check?  I believe you implied that this didn't result in a failure.
It would have happened on exit from the method, if anything.

On Thu, Nov 25, 2021 at 12:49 PM Roland Müller  wrote:

> Yes. Actually I only tested with a non-existing file.
>
> But if you mean that case were also the directory is missing: behavior is
> still the same.
>
> BR,
> Roland
>
> func main() {
> f, err := os.Open("/tmp/dat_is_net_do/dat")
> //defer f.Close()
> fmt.Printf("%v\n", f)
> if err != nil {
>   fmt.Println("NO FILE")
>   //return
>}
>defer f.Close()
>fmt.Println("END")
> }
>
>
> Am Do., 25. Nov. 2021 um 21:43 Uhr schrieb David Karr <
> davidmichaelk...@gmail.com>:
>
>> And did you test that with a file path that would fail?
>>
>> On Thu, Nov 25, 2021, 11:40 Roland Müller  wrote:
>>
>>> Hello,
>>>
>>> actually trying this with os.Open() the program behaves the same
>>> regardless whether the defer is before or after the error handling, Thus,
>>> no panic :-)
>>>
>>> Isn't anything declared with defer always running after the user code in
>>> the given func ends? I am too tired now to look this up.
>>>
>>> BR,
>>>
>>> Roland
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "os"
>>> )
>>>
>>> func main() {
>>> f, err := os.Open("/tmp/dat")
>>> //defer f.Close()
>>> fmt.Printf("%v\n", f)
>>> if err != nil {
>>>   fmt.Println("NO FILE")
>>>   //return
>>>}
>>>defer f.Close()
>>>fmt.Println("END")
>>> }
>>>
>>> Output:
>>> 
>>> NO FILE
>>> END
>>>
>>>
>>> On 11/25/21 10:19, Fannie Zhang wrote:
>>>
>>> OK, I see. Thank you.
>>>
>>>
>>>
>>> *From:* Kurtis Rader  
>>> *Sent:* Thursday, November 25, 2021 10:26 AM
>>> *To:* Fannie Zhang  
>>> *Cc:* golang-nuts 
>>> 
>>> *Subject:* Re: [go-nuts] some incorrect code in blog.
>>>
>>>
>>>
>>> Notice the date of that blog article: 2010-08-04. It's more than eleven
>>> years old. Blog articles are not updated as the language changes. However,
>>> in this case the example in that article is correct. If `os.Open()` returns
>>> an error then the `src` return value is invalid.
>>>
>>>
>>>
>>> On Wed, Nov 24, 2021 at 6:14 PM Fannie Zhang 
>>> wrote:
>>>
>>> Hi all,
>>>
>>>
>>>
>>> There is some incorrect code in
>>> https://go.dev/blog/defer-panic-and-recover blog.
>>>
>>>
>>>
>>> The original code is
>>>
>>> *func CopyFile() {*
>>>
>>> *   ...*
>>>
>>> *   if err != nil {*
>>>
>>> *  return*
>>>
>>> *   }*
>>>
>>> *   defer src.Close()*
>>>
>>> *   ...*
>>>
>>> *}*
>>>
>>>
>>>
>>> I think the correct code should be
>>>
>>> *func CopyFile() {*
>>>
>>> *   ...*
>>>
>>> *   defer src.Close()*
>>>
>>> *   if err != nil {*
>>>
>>> *  return*
>>>
>>> *   }*
>>>
>>> *   ...*
>>>
>>> *}*
>>>
>>>
>>>
>>> I do not know how to modify the go blog, can anyone help? Thank you.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Fannie Zhang
>>>
>>> --
>>> 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/726e95ed-9b14-46a5-bb09-7821616f4ff9n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/726e95ed-9b14-46a5-bb09-7821616f4ff9n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Kurtis Rader
>>>

Re: [go-nuts] some incorrect code in blog.

[David Karr]

And did you test that with a file path that would fail?

On Thu, Nov 25, 2021, 11:40 Roland Müller  wrote:

> Hello,
>
> actually trying this with os.Open() the program behaves the same
> regardless whether the defer is before or after the error handling, Thus,
> no panic :-)
>
> Isn't anything declared with defer always running after the user code in
> the given func ends? I am too tired now to look this up.
>
> BR,
>
> Roland
>
> package main
>
> import (
> "fmt"
> "os"
> )
>
> func main() {
> f, err := os.Open("/tmp/dat")
> //defer f.Close()
> fmt.Printf("%v\n", f)
> if err != nil {
>   fmt.Println("NO FILE")
>   //return
>}
>defer f.Close()
>fmt.Println("END")
> }
>
> Output:
> 
> NO FILE
> END
>
>
> On 11/25/21 10:19, Fannie Zhang wrote:
>
> OK, I see. Thank you.
>
>
>
> *From:* Kurtis Rader  
> *Sent:* Thursday, November 25, 2021 10:26 AM
> *To:* Fannie Zhang  
> *Cc:* golang-nuts 
> 
> *Subject:* Re: [go-nuts] some incorrect code in blog.
>
>
>
> Notice the date of that blog article: 2010-08-04. It's more than eleven
> years old. Blog articles are not updated as the language changes. However,
> in this case the example in that article is correct. If `os.Open()` returns
> an error then the `src` return value is invalid.
>
>
>
> On Wed, Nov 24, 2021 at 6:14 PM Fannie Zhang  wrote:
>
> Hi all,
>
>
>
> There is some incorrect code in
> https://go.dev/blog/defer-panic-and-recover blog.
>
>
>
> The original code is
>
> *func CopyFile() {*
>
> *   ...*
>
> *   if err != nil {*
>
> *  return*
>
> *   }*
>
> *   defer src.Close()*
>
> *   ...*
>
> *}*
>
>
>
> I think the correct code should be
>
> *func CopyFile() {*
>
> *   ...*
>
> *   defer src.Close()*
>
> *   if err != nil {*
>
> *  return*
>
> *   }*
>
> *   ...*
>
> *}*
>
>
>
> I do not know how to modify the go blog, can anyone help? Thank you.
>
>
>
> Best regards,
>
> Fannie Zhang
>
> --
> 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/726e95ed-9b14-46a5-bb09-7821616f4ff9n%40googlegroups.com
> 
> .
>
>
>
>
> --
>
> Kurtis Rader
>
> Caretaker of the exceptional canines Junior and Hank
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you. --
> 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/PAXPR08MB6640963981E13AC180B4E19594629%40PAXPR08MB6640.eurprd08.prod.outlook.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/4d0b379f-c2a0-a314-e2d3-5fec36528845%40gmail.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/CAA5t8Vq9m6rrR3GRcUqq-iKZc%3DX0okVuC6%2BPbH3n0zJx-SMZ7w%40mail.gmail.com.

Re: [go-nuts] some incorrect code in blog.

[David Karr]

On Wed, Nov 24, 2021 at 6:14 PM Fannie Zhang  wrote:

> Hi all,
>
> There is some incorrect code in
> https://go.dev/blog/defer-panic-and-recover blog.
>
> The original code is
> *func CopyFile() {*
> *   ...*
> *   if err != nil {*
> *  return*
> *   }*
> *   defer src.Close()*
> *   ...*
> *}*
>
> I think the correct code should be
> *func CopyFile() {*
> *   ...*
> *   defer src.Close()*
> *   if err != nil {*
> *  return*
> *   }*
> *   ...*
> *}*
>
> I do not know how to modify the go blog, can anyone help? Thank you.
>

Well, I would call myself a Go newbie, but I would think that if err !=
nil, that means there was an error, so the value of "src" would be either
invalid or nil, so putting the "defer" before the err check would possibly
result in a panic. I'd say the original code is correct.


> Best regards,
> Fannie Zhang
>
> --
> 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/726e95ed-9b14-46a5-bb09-7821616f4ff9n%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/CAA5t8Vp4-dYHApveOObvQMXqg0s%2B_8Lu1WhCDKgyB8rst9cytw%40mail.gmail.com.

[go-nuts] Re: Getting "cgo argument has Go pointer to Go pointer"

[David Karr]

On Monday, November 15, 2021 at 3:49:20 PM UTC-8 David Karr wrote:

>
> I'm pretty new to Go (many years in other languages).  I'm trying to use 
> cgo to use a C library we're using.
>
> I have the following line of code, which is compiling (that's been enough 
> of a struggle):
>
> status = int(C.VeProtect(C.VeObj(fpeProtect), ))
>
> This is failing at runtime with 
> 
> panic serving [::1]:55146: runtime error: cgo argument has Go pointer to 
> Go pointer goroutine 20 [running]: net/http.(*conn).serve.func1() 
> /usr/local/go/src/net/http/server.go:1801 +0x13a panic({0xc21cc0, 
> 0xc93700}) /usr/local/go/src/runtime/panic.go:1047 +0x262 voltagems
> /voltagefuncs.protectAndAccess.func1(0x0, 0xcb2960) 
> /media/sf_winhome/git/voltagego/voltagefuncs/voltagefuncs.go:71 +0x90
> 
>
> The first thing that's frustrating about this error is that I can't tell 
> which argument it's talking
> about. I would guess it's the first one, as it's more complicated than the 
> second.
>
> The type of "fpeProtect" is "C.VeFPE", and "C.VeObj" is an alias for 
> "void*".
>
> And "C.VeFPE" is defined as:
>
> type _Ctype_VeFPE *_Ctype_struct_VeFPE_st
>
> Any suggestions?
>
>
Note that all the properties of this structure are set by C functions. All 
I do is define the variable and pass a pointer to it to functions. 

Also, I saw one note that suggesting that setting "GODEBUG=cgocheck=0" 
might disable this check (not sure if that will help me or not), but I'm 
using vscode for this, and I don't know how to set the GO environment 
variables.

-- 
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/17f65eee-5da7-4194-945c-2e34f65a372an%40googlegroups.com.

[go-nuts] Getting "cgo argument has Go pointer to Go pointer"

[David Karr]

I'm pretty new to Go (many years in other languages).  I'm trying to use 
cgo to use a C library we're using.

I have the following line of code, which is compiling (that's been enough 
of a struggle):

status = int(C.VeProtect(C.VeObj(fpeProtect), ))

This is failing at runtime with 

panic serving [::1]:55146: runtime error: cgo argument has Go pointer to Go 
pointer goroutine 20 [running]: net/http.(*conn).serve.func1() 
/usr/local/go/src/net/http/server.go:1801 +0x13a panic({0xc21cc0, 
0xc93700}) /usr/local/go/src/runtime/panic.go:1047 +0x262 voltagems
/voltagefuncs.protectAndAccess.func1(0x0, 0xcb2960) 
/media/sf_winhome/git/voltagego/voltagefuncs/voltagefuncs.go:71 +0x90


The first thing that's frustrating about this error is that I can't tell 
which argument it's talking
about. I would guess it's the first one, as it's more complicated than the 
second.

The type of "fpeProtect" is "C.VeFPE", and "C.VeObj" is an alias for 
"void*".

And "C.VeFPE" is defined as:

type _Ctype_VeFPE *_Ctype_struct_VeFPE_st

Any suggestions?

-- 
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/f89005a3-6cbf-4f4c-bc90-3cdb1e6eb87cn%40googlegroups.com.

Re: [go-nuts] Which error handling pattern do you prefer?

[David Finkel]

On Fri, Nov 12, 2021 at 7:48 AM Miguel Angel Rivera Notararigo <
ntr...@gmail.com> wrote:

> I tend to use errX (X is adapted according to context) for function scoped
> errors, and err for block scoped errors
>
> func MyFunc() error {
>>   v, errDS := doSomething()
>>   ...
>>   errDA := doAnotherthing()
>> }
>>
>
> if err := doAnotherthing(); err != nil {
>> return err
>> }
>>
>
> That way you don't shadow errors.
>


I can't +1 this enough.

I've caught *so* many bugs from shadowed errors (and re-used error
variables). I consider it a rather bad anti-pattern to have a single
err variable
that's reused throughout a scope.
If you have unique error variable names and you forget to do something with
an error that you've assigned a name you automatically get unused variable
compile-errors. (just this is enough to be worthwhile)


With that said, constraining the scope using the initializer statement on
an if (or switch) statement suffices when you don't need any other return
values, at which point I may use the err variable-name (although I often
make those unique for clarity anyway).

> --
> 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/CAF9DLCmR4ZdnVs4A28BSrPcbiHsQ_ufub5cSPjCt2SDy2dA1xA%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/CANrC0Bjc%2BTgHZvdY9oAqBgBUFDdd-KbkMi38bHmeYHPaDZANPA%40mail.gmail.com.

Re: [go-nuts] HPC image processing in go?

[David Finkel]

On Thu, Nov 4, 2021 at 5:43 AM quin...@gmail.com  wrote:

> Hi,
>
> Has anyone got any experience of high performance image processing in go?
>
> By this I mean doing complex image processing in real time at 4K
> resolution on commodity hardware. This is really pushing it using carefully
> written C++ but when we tried writing similar code using go slices we go a
> significant slowdown (x4 over gcc).
>
> We experimented using unsafe pointers thinking it is go's slice range
> checking that cause the problems, but surprisingly saw no improvement.
>
> Has anyone had success saturating the memory bandwidth using go?  Is my
> result a surprise to people? Is it just that gcc's code generator is very
> mature and Go's is less so, or should I keep looking for dropoffs in my
> code?
>
This doesn't particularly surprise me. The Go GC compiler is optimised for
fast compile-times and does very limited vectorization.

I think the general advice in cases where one needs better optimization
paths has been to use gccgo or gollvm (if possible).


>
> I haven't looked at the generated assembly yet, but that is my next step.
>
> Any opinions?
>
> -Steve
>
> --
> 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/8419a816-8058-48c1-874b-09a34be0f3fcn%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/CANrC0Bgua02tU4h1QayM%2BHVmOWNznKnYiSdzFTsKkUT_wVZNYw%40mail.gmail.com.

Re: [go-nuts] Re: Why go plugin addresses do not load with go binary #49225

[David Finkel]

On Mon, Nov 1, 2021 at 9:44 AM Manoj Chauhan 
wrote:

> Hi Brian,
>
> greeter.go calls plugin.open and it will be work only for one sub version
> of go. If plugin and binary are made in different sub versions of go1.15
> then plugin.open will not work.
>
It sounds like you want to ignore a major warning on the use of plugins.
It's my understanding that go plugins' limitations on requiring that both
the plugin and the main binary to be built with identical toolchains (same
go version) comes from the lack of a stable internal ABI within Go binaries
across versions. (also the possibility of runtime changes across versions).
Using LD_PRELOAD does not seem advisable as a way to bypass that
limitation. (unfortunately, I don't have a better option other than to more
tightly constrain your build system so both the original binary and the
plugin are built with the same toolchain)

>
> On Monday, November 1, 2021 at 6:55:02 PM UTC+5:30 Brian Candler wrote:
>
>> > My question was how to load plugin address in go runtime using
>> LD_PRELOAD. I am using LD_PRELOAD because plug.open is failed. Is there any
>> other solution?
>>
>> When I tried it, I didn't need to set any environment variables (and
>> certainly no LD_XXX variables).  Follow this tutorial:
>>
>> https://medium.com/learning-the-go-programming-language/writing-modular-go-programs-with-plugins-ec46381ee1a9
>>
>> It works fine for me:
>>
>> ubuntu@builder:~/go-plugin-example$ *cat /etc/lsb-release*
>> DISTRIB_ID=Ubuntu
>> DISTRIB_RELEASE=18.04
>> DISTRIB_CODENAME=bionic
>> DISTRIB_DESCRIPTION="Ubuntu 18.04.5 LTS"
>> ubuntu@builder:~/go-plugin-example$ *ls*
>> LICENSE  README.md  chi  eng  greeter.go  swe
>> ubuntu@builder:~/go-plugin-example$ *go version*
>> go version go1.16.6 linux/amd64
>> ubuntu@builder:~/go-plugin-example$ *go build -buildmode=plugin -o
>> eng/eng.so eng/greeter.go*
>> ubuntu@builder:~/go-plugin-example$ *go run greeter.go english*
>> Hello Universe
>> ubuntu@builder:~/go-plugin-example$
>>
>> If you're still using Ubuntu 16, note that it went obsolete nearly a year
>> ago (unless you're paying for extended maintenance).
>>
> --
> 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/42e3d250-cb69-43b6-a297-7a56fcbe688en%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/CANrC0BiRTDZpQ5SiAxk2%2BDT5hV1vYzZRiJgtpsUSPkdsbiC%2B%3DQ%40mail.gmail.com.

Re: [go-nuts] ast.NewPackage errors for built in types

[David Finkel]

On Mon, Oct 11, 2021 at 5:48 AM Steven Hartland 
wrote:

> If the ast.Files passed to ast.NewPackage includes built in types such as
> int it returns an error e.g.
> file1.go:5:6: undeclared name: int
>
> Is there a way to prevent that?
>

Generally, I always add the `builtin` package to the list of packages I'm
parsing.
I wrote a little library for exactly this kind of package loading a few
years ago:
https://gitlab.com/dfinkel/goastpkg/-/blob/master/go_ast_parser.go
(https://pkg.go.dev/golang.spin-2.net/astpkg)

>
> Playground example: https://play.golang.org/p/Yg30TTzoLHP
>
> My goal is to take multiple files, resolve inter file dependencies e.g. a
> type referencing another type in a different file and process the resulting
> ast.Files. So if there is a better way to achieve this I'm all ears.
>

In general, I've stopped using the `go/ast` internal references as much and
have started using resolved `go/types` references as they're more reliable
and better-specified.
(golang.org/x/tools/go/packages
 has a LoadMode
flag for generating `go/types.Info` (NeedTypesInfo
))

>
>Regards
>Steve
>
> --
> 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/CAHEMsqbJoJxuo3c-mofMtzXXJhYCzV2skW2ZB3ZPY6WtA8%2BxHw%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/CANrC0BiwYY32yTC-SivuYm2-pYEuxeuf4KEz%2BatjeLoAsLr27g%40mail.gmail.com.

Re: [go-nuts] Draining http response bodies

[David Riley]

On Oct 7, 2021, at 3:36 AM, Amnon  wrote:
> 
> Is it necessary for a http client to fully read the http response body?
> 
> Opinion on the Go forums seems divided 
> https://forum.golangbridge.org/t/do-i-need-to-read-the-body-before-close-it/5594
> 
> But a simple benchmark https://play.golang.org/p/5JDWYbRe0lD
> suggests that leaving unread data in the response body will prevent 
> the connection being reused, and much slower performance.
> 
> The documentation https://pkg.go.dev/net/http states:
> "The client must close the response body when finished with it:"
> 
> The following example does include a call to io.ReadAll(resp.Body) 
> but it does not spell out whether there would be a performance penalty
> for failing to read the entire body.
> 
> It would be good if the standard library documentation was a bit more 
> explicit here.

I suspect a lot of this actually comes down to operating system level handling 
of TCP sockets, which is something that it would be hard for the docs to 
address other than maybe offering a warning that your OS *might* not release 
the port for reuse if the body isn't fully drained.

I could be wrong, though, there's half a chance it's really a GC thing instead. 
 I'd have to look at the source to be sure.


- Dave

-- 
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/03EA0EA9-45BA-454E-B991-9AF8FFC84111%40gmail.com.

[go-nuts] Re: What is up with memo.com?

[David Taylor]

I've just been made aware of this, and we're looking into getting it fixed. 

I apologize for the unwanted emails — it should not be happening. Would 
anyone care to forward me what we're sending you if you have the chance? 

Dave

On Tuesday, September 21, 2021 at 1:19:06 PM UTC-7 Brian Candler wrote:

> I've seen the same too.  Sadly memo.com don't provide any opt-out link in 
> their messages.
>
> Based on IP addresses in headers, the parent appears to be 
> https://joylabs.com/.  I tried contacting them via their web contact 
> form, but have had no response.
>  
> On Tuesday, 21 September 2021 at 17:48:20 UTC+1 peterGo wrote:
>
>> Ian,
>>
>> I received some gmail from memo.com for a golang-nuts conversation that 
>> I participated in. I marked the gmail messages as spam.
>>
>> Peter
>>
>> On Tuesday, September 21, 2021 at 12:11:31 PM UTC-4 Ian Lance Taylor 
>> wrote:
>>
>>> I'm seeing random repeats of golang-nuts messages sent from memo.com 
>>> with bad formatting. I'm also seeing regular messages telling me that 
>>> someone has connected with golang-nuts on memo.com, which I've been 
>>> rejecting at the moderation stage. 
>>>
>>> Does anybody know what is going on? I don't want to start marking all 
>>> these messages as spam if they are useful in some way, but so far I 
>>> don't see it. 
>>>
>>> Thanks. 
>>>
>>> Ian 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/409a962c-57d8-4eb1-9647-443ec76be3f9n%40googlegroups.com.

Re: [go-nuts] Idea extending xerror.As

[David Finkel]

On Mon, Sep 20, 2021 at 10:52 PM Andrey T. 
wrote:

>
> ... or, to put a crazy idea out there, we need to ask for extension of
> switch statement to support (v, err) tuples for a case argument...


That's not a particularly crazy idea. It's just one that's unlikely to make
it through with one use-case like this since the bar for language changes
is so much higher than standard library changes. (for good reason)

On Sunday, September 19, 2021 at 3:43:36 PM UTC-6 david@gmail.com wrote:
>
>> On Sun, Sep 19, 2021 at 5:19 PM roger peppe  wrote:
>>
>>> In some ways, the existing API is arguably more ergonomic than the
>>> originally proposed generic version, as it's possible to use `errors.As` in
>>> a switch statement (eg to test several possible types of error) which isn't
>>> possible with the multi-return `As` variant.
>>>
>>
>> Hmm, that's a good point.
>> However, the main reason I like the two-return-value version more is that
>> you can use it like a normal type-assertion in an if-statement's init
>> section.
>>
>>
>>> A minor variant of the existing API could be:
>>>
>>> ```
>>> func As[E error](err error, asErr *E) bool
>>> ```
>>> which makes the API a little clearer without changing the usage. Sadly
>>> we can't make that change without breaking compatibility.
>>>
>>> Unfortunately, in order to use this proposed version, you still need to
>> pre-declare the variables for each type before the switch/case.
>> I've honestly found it more ergonomic to use a if/else if/ block rather
>> than a switch/case because it lets me contain the scope of these variables
>> anyway.
>>
>> I suppose a simple wrapper that can be used with type-assertions inside a
>> switch/case block would be:
>> ```
>> func AsBool[E error](err error, asErr error) bool {
>> ae, ok := As[E](err)
>> if ok {
>>  asErr = ae
>> }
>> return ok
>> }
>> ```
>> (this would definitely need a better name)
>>
>> Then you'd be able to almost treat your switch/case like a type-switch
>> without needing to pre-declare a variable for every case.
>>
>> ```
>> var asErr error
>> switch {
>>case errors.AsBool[*os.PathError](err, ):
>>fmt.Printf("Path Error! ae: %v", asErr.(*os.PathError))
>>case errors.AsBool[syscall.Errno](err, ):
>>fmt.Printf("ae: %d", asErr.(syscall.Errno))
>> }
>> ```
>>
>> However, I think it would be nicer to use the (originally proposed)
>> two-return errors.As with if/else if.
>>
>> ```
>> if pe, ok := errors.As[*os.PathError](err); ok {
>> fmt.Printf("Path Error: %v", pe)
>> } else if en, ok := errors.As[syscall.Errno](err); ok {
>> fmt.Printf("errno %[1]d: %[1]s", en)
>> }
>> ```
>>
>> Since it looks like the dev.typeparams branch has been merged into
>> master, I was just thinking about how we'd add the two-return-value/generic
>> version of As to the errors package (for go 1.18).
>> Given that the original proposal's code works pretty much as-is, I think
>> the biggest barrier would be a good name. (given that As is already taken)
>>
>>>
>>> On Sun, 19 Sep 2021, 21:15 David Finkel,  wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Sun, Sep 19, 2021 at 4:02 PM David Finkel 
>>>> wrote:
>>>>
>>>>> You might be interested in the original draft proposal for errors.As:
>>>>>
>>>>> https://go.googlesource.com/proposal/+/master/design/go2draft-error-inspection.md#the-is-and-as-functions
>>>>>
>>>>> In particular, it originally specified that errors.As would take a
>>>>> type-parameter. (the version of generics that was proposed concurrently
>>>>> with that proposal was not accepted so they had to go with the current
>>>>> (clunkier) interface).
>>>>>
>>>>
>>>> Hmm, actually, the code in that proposal for the generic version of
>>>> errors.As works almost unchanged:
>>>> https://go2goplay.golang.org/p/ddPDlk00Cbl (I just had to change the
>>>> type-parameter syntax)
>>>>
>>>>
>>>>> On Sun, Sep 19, 2021 at 5:33 AM Haddock  wrote:
>>>>>
>>>>>>
>>>>>> I like the way error handling is done in the xerror package. Things
>>>>>> become more concise, but remain very easy to read and understa

Re: [go-nuts] Idea extending xerror.As

[David Finkel]

On Sun, Sep 19, 2021 at 5:19 PM roger peppe  wrote:

> In some ways, the existing API is arguably more ergonomic than the
> originally proposed generic version, as it's possible to use `errors.As` in
> a switch statement (eg to test several possible types of error) which isn't
> possible with the multi-return `As` variant.
>

Hmm, that's a good point.
However, the main reason I like the two-return-value version more is that
you can use it like a normal type-assertion in an if-statement's init
section.


> A minor variant of the existing API could be:
>
> ```
> func As[E error](err error, asErr *E) bool
> ```
> which makes the API a little clearer without changing the usage. Sadly we
> can't make that change without breaking compatibility.
>
> Unfortunately, in order to use this proposed version, you still need to
pre-declare the variables for each type before the switch/case.
I've honestly found it more ergonomic to use a if/else if/ block rather
than a switch/case because it lets me contain the scope of these variables
anyway.

I suppose a simple wrapper that can be used with type-assertions inside a
switch/case block would be:
```
func AsBool[E error](err error, asErr error) bool {
ae, ok := As[E](err)
if ok {
 asErr = ae
}
return ok
}
```
(this would definitely need a better name)

Then you'd be able to almost treat your switch/case like a type-switch
without needing to pre-declare a variable for every case.

```
var asErr error
switch {
   case errors.AsBool[*os.PathError](err, ):
   fmt.Printf("Path Error! ae: %v", asErr.(*os.PathError))
   case errors.AsBool[syscall.Errno](err, ):
   fmt.Printf("ae: %d", asErr.(syscall.Errno))
}
```

However, I think it would be nicer to use the (originally proposed)
two-return errors.As with if/else if.

```
if pe, ok := errors.As[*os.PathError](err); ok {
fmt.Printf("Path Error: %v", pe)
} else if en, ok := errors.As[syscall.Errno](err); ok {
fmt.Printf("errno %[1]d: %[1]s", en)
}
```

Since it looks like the dev.typeparams branch has been merged into master,
I was just thinking about how we'd add the two-return-value/generic version
of As to the errors package (for go 1.18).
Given that the original proposal's code works pretty much as-is, I think
the biggest barrier would be a good name. (given that As is already taken)

>
> On Sun, 19 Sep 2021, 21:15 David Finkel,  wrote:
>
>>
>>
>>
>> On Sun, Sep 19, 2021 at 4:02 PM David Finkel 
>> wrote:
>>
>>> You might be interested in the original draft proposal for errors.As:
>>>
>>> https://go.googlesource.com/proposal/+/master/design/go2draft-error-inspection.md#the-is-and-as-functions
>>>
>>> In particular, it originally specified that errors.As would take a
>>> type-parameter. (the version of generics that was proposed concurrently
>>> with that proposal was not accepted so they had to go with the current
>>> (clunkier) interface).
>>>
>>
>> Hmm, actually, the code in that proposal for the generic version of
>> errors.As works almost unchanged:
>> https://go2goplay.golang.org/p/ddPDlk00Cbl (I just had to change the
>> type-parameter syntax)
>>
>>
>>> On Sun, Sep 19, 2021 at 5:33 AM Haddock  wrote:
>>>
>>>>
>>>> I like the way error handling is done in the xerror package. Things
>>>> become more concise, but remain very easy to read and understand as in
>>>> plain Go errorhandling.
>>>>
>>>> Here is the example of how to use xerror.As:
>>>>
>>>> _, err := os.Open("non-existing")
>>>> if err != nil {
>>>> var pathError *os.PathError
>>>> if xerrors.As(err, ) {
>>>> fmt.Println("Failed at path:", pathError.Path)
>>>> }
>>>> }
>>>>
>>>> My idea is to make this even shorter like this:
>>>>
>>>> _, err := os.Open("non-existing")
>>>> myerrors.As(err, os.PathError) {
>>>>  pathError -> fmt.Println("Failed at path:", pathError.Path)
>>>> }
>>>>
>>>> Think something like that has so far not been suggested. That's why I
>>>> thought it is justified to drop comment.
>>>>
>>>> myerrors.As would also do the check if err is nil. The code in my
>>>> sample is not valid Go code, I know. It is only pseudo code to show the
>>>> idea.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "golang-nuts" group.
&g

Re: [go-nuts] Idea extending xerror.As

[David Finkel]

On Sun, Sep 19, 2021 at 4:02 PM David Finkel  wrote:

> You might be interested in the original draft proposal for errors.As:
>
> https://go.googlesource.com/proposal/+/master/design/go2draft-error-inspection.md#the-is-and-as-functions
>
> In particular, it originally specified that errors.As would take a
> type-parameter. (the version of generics that was proposed concurrently
> with that proposal was not accepted so they had to go with the current
> (clunkier) interface).
>

Hmm, actually, the code in that proposal for the generic version of
errors.As works almost unchanged: https://go2goplay.golang.org/p/ddPDlk00Cbl (I
just had to change the type-parameter syntax)


> On Sun, Sep 19, 2021 at 5:33 AM Haddock  wrote:
>
>>
>> I like the way error handling is done in the xerror package. Things
>> become more concise, but remain very easy to read and understand as in
>> plain Go errorhandling.
>>
>> Here is the example of how to use xerror.As:
>>
>> _, err := os.Open("non-existing")
>> if err != nil {
>> var pathError *os.PathError
>> if xerrors.As(err, ) {
>> fmt.Println("Failed at path:", pathError.Path)
>> }
>> }
>>
>> My idea is to make this even shorter like this:
>>
>> _, err := os.Open("non-existing")
>> myerrors.As(err, os.PathError) {
>>  pathError -> fmt.Println("Failed at path:", pathError.Path)
>> }
>>
>> Think something like that has so far not been suggested. That's why I
>> thought it is justified to drop comment.
>>
>> myerrors.As would also do the check if err is nil. The code in my sample
>> is not valid Go code, I know. It is only pseudo code to show the idea.
>>
>> --
>> 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/629e6763-36a9-4d7d-991c-fd71dd384d0en%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/629e6763-36a9-4d7d-991c-fd71dd384d0en%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CANrC0BgsVSo0hv5UtTi%3DVXZYZODys1H-kvB63o2B3UThBMnfxQ%40mail.gmail.com.

Re: [go-nuts] Idea extending xerror.As

[David Finkel]

You might be interested in the original draft proposal for errors.As:
https://go.googlesource.com/proposal/+/master/design/go2draft-error-inspection.md#the-is-and-as-functions

In particular, it originally specified that errors.As would take a
type-parameter. (the version of generics that was proposed concurrently
with that proposal was not accepted so they had to go with the current
(clunkier) interface).

On Sun, Sep 19, 2021 at 5:33 AM Haddock  wrote:

>
> I like the way error handling is done in the xerror package. Things become
> more concise, but remain very easy to read and understand as in plain Go
> errorhandling.
>
> Here is the example of how to use xerror.As:
>
> _, err := os.Open("non-existing")
> if err != nil {
> var pathError *os.PathError
> if xerrors.As(err, ) {
> fmt.Println("Failed at path:", pathError.Path)
> }
> }
>
> My idea is to make this even shorter like this:
>
> _, err := os.Open("non-existing")
> myerrors.As(err, os.PathError) {
>  pathError -> fmt.Println("Failed at path:", pathError.Path)
> }
>
> Think something like that has so far not been suggested. That's why I
> thought it is justified to drop comment.
>
> myerrors.As would also do the check if err is nil. The code in my sample
> is not valid Go code, I know. It is only pseudo code to show the idea.
>
> --
> 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/629e6763-36a9-4d7d-991c-fd71dd384d0en%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/CANrC0Bi2azNEa33sAk2S4vYCzQEkQJovqOUWeWBDg%3DKokvQL6w%40mail.gmail.com.

[go-nuts] Right way to fan out work loads

[David Belle-Isle]

Hi,

I've been facing this question for a while and never managed to find the 
"right" answer. Hopefully this forum will be able to enlighten me a little 
bit.

Given a very simple pattern: Consume some data, transform it, store it 
(ETL). The storing part is slow(er) and needs to be fanned out.

The question: What's the best (correct? idiomatic?) way to implement that 
in Go?

A) From "main", buffer the incoming data and launch a goroutine and pass it 
the data to store. Similar to how you could implement a web server handling 
an incoming connection in Go.

OR

B) From "main", create N channels and spin up N goroutines to send down 
data to workers. Round-robin writes to the N channels.
B1) Do you buffer the data in "main" or after the channel, in the goroutine?

I understand that (A) can spin out of control and launch too many 
goroutines and (B) can run into a bottle neck. Each of these problems can 
be easily addressed. I'm more interested in hearing what you think is the 
"right" way to solve this problem?

Thanks

David

-- 
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/6ba8cf62-8711-4c39-bf6c-f255727385ffn%40googlegroups.com.

Re: [go-nuts] Re: WASM Performance

[David Suarez]

 
 
  
   reading emails in reverse, apologies, may be similar to what I just sent.  Is it easy enough to try the request animation frame approach?  may help rule out an error in web worker code or approach if you emulate his flow to start, then start optimizing back to web worker if it solves to avoid whatever may have caused the delta.  Just a thought
  
  
   
On 09/05/2021 10:13 AM Stephen Illingworth  wrote:
   
   

   
   

   
   
Thanks for that, it was interesting reading. The problem he was describing in the Doom case seems to be have been caused by the WASM program taking up all the CPU time, meaning the browser itself is unresponsive. I've solved that by using a Web Worker. From what I understand requestAnimationFrame() is a different solution to the same problem. Somebody correct me if I'm wrong.

   
   

   
   
What is interesting though is the profile differences between his Doom port and my 2600 emulator. The top image is from the Doom port:
   
   

   
   

   
   

   
   

   
   
And this is from Web2600, over a similar time period:

   
   

   
   

   
   

   
   

   
   
We can see a lot more gaps in the second case than the first, which would account for the performance drop I think.
   
   

   
   
Does this bring me closer to a solution?

   
   

   
   

 On Sunday, 5 September 2021 at 13:28:44 
 


 I had read an article that may be useful (format was different so may not be the same) -->  https://github.com/diekmann/wasm-fizzbuzz  (goes from basic WASM to Doom)
 
  
 
 
  The key thing in the Doom port that I recall was needed was to change the perspective of the owning thread (now the browser) so needed to ensure it was never blocked/ responded quickly.  When you read through you may find your answer or something that gives you an idea to start searching through in your code.  
 
 
  
 
 
  Hope it helps, David
 

   
   -- 
   You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
   To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/N10hzvkDA1A/unsubscribe.
   To unsubscribe from this group and all its topics, 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/aa9b40d9-b154-48dd-bb52-62f139e3bceen%40googlegroups.com.
   
  
  
   
  
  
   Sincerely,
   David Suarez
   Gallup Strengths Finder:  Achiever * Strategic * Relator * Ideation * Learner
   https://www.linkedin.com/in/davidjsuarez/ 
  
 




-- 
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/1023779990.108994.1631069424500%40email.ionos.com.

Re: [go-nuts] Re: WASM Performance

[David Suarez]

 
 
  
   Did moving rendering to the browser side (just have the other side prep the data to be rendered) solve for the difference?  how much?  Did he do the same in the Doom article to get it to OK?
  
  
   
On 09/07/2021 8:34 AM Stephen Illingworth  wrote:
   
   

   
   

   
   
Yes. I'm seeing a 10x difference in speed too. So at least I know I'm not doing anything fundamentally wrong. It's a general problem at the moment.

   
   

   
   
Thanks. 

   
   

 On Tuesday, 7 September 2021 at 09:31:41 UTC+1 ma...@eliasnaur.com wrote:
 


 In my experience (Gio projects), WASM is very slow compared to native code; my investigations are part of #32591. You may find https://github.com/golang/go/issues/32591#issuecomment-517835565 relevant, because I cut out rendering to eliminate the JS<=>Go crossing overhead. It was a ~10x difference in 2019 and I don't think anything major has changed since then.
 
 Elias
 

   
   -- 
   You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
   To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/N10hzvkDA1A/unsubscribe.
   To unsubscribe from this group and all its topics, 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/6893845f-894b-4546-bb3e-f811e61c01ben%40googlegroups.com.
   
  
  
   
  
  
   Sincerely,
   David Suarez
   Gallup Strengths Finder:  Achiever * Strategic * Relator * Ideation * Learner
   https://www.linkedin.com/in/davidjsuarez/ 
  
 




-- 
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/143741806.108972.1631069234142%40email.ionos.com.

Re: [go-nuts] Re: Makefiles for Go Programs

[David Riley]

On Aug 23, 2021, at 12:48, Roland Müller  wrote:
> 
> What are the alternatives to Makefile that are used by Go developers? Please 
> comment :-)

Well, there’s mage, which aims to more or less replace the functionality of 
Make for Go. I’m not really sold on *needing* a replacement for Make, and if 
you’re doing CI builds, it still adds an external dependency, but it is an 
interesting project: https://magefile.org/

> I know Make from old C/C++ times. Therefore, my picture is that it is not 
> very portable and requires for quite many operations the usage of external 
> tools that again differ between the platforms. Basically Makefiles are 
> somehow enhanced shell scripts (Linux/Unix) or batch files (Windows).

Makefiles are quite portable, at least assuming you’re using GNU Make (which is 
at least available nearly everywhere). It may not be the most ideal option with 
Windows, but nearly everywhere else it’s pretty solid.

If you have problems with external tools behaving differently across platforms 
(the behavior of “which” on Solaris vs. Linux or BSD being a particular 
sticking point I’ve run across in scripts), I would argue that there’s not much 
out there that’s going to solve that problem.

> Currently, at work I deal a lot with Maven, that is a bit too Java -oriented 
> in spite of being capable in principle to build and compile other things too. 
> Another, issue is the XML syntax that's makes editing without tool support 
> very hard.

Most of the newer build tools like Maven, Gradle and Bazel seem to be more 
oriented towards either IDEs or large-scale projects. Make scales quite nicely 
to small, and moderately well to large. Recursive builds tend to be a problem, 
but fortunately with Go, you don’t tend to need those.

I would say Go tooling goes along rather well with Make if you’re following the 
semi-canonical repo structure, because you can tell Go to just build a list of 
executables from the ./cmd directory and the build tool takes care of caching, 
figuring out dependencies, etc. Not much in the way of portability issues there.

> Gradle would be another candidate. I am just began to explore it. It's a bit 
> like Maven with human syntax, but lacks again on lifecycle support that I 
> like with Maven.

I feel like Gradle is another very Java-oriented tool, and as a consequence 
seems to have inherited the very Byzantine nature of nearly every other Java 
ecosystem tool. I haven’t tried to use it for non-Java stuff, but I wouldn’t, 
personally. Not least because in a CI environment, I tend to try to stick to 
things either native to the language I’m using (so, the native Go build tools, 
*maybe* mage), or things present or easily installed in the host Docker image 
(both Bourne shell and Make fit this bill nicely).

The other benefit here is that in the projects I work on for work, not everyone 
wants to use Make (some folks have a pathological aversion to it), but it’s 
easy for us to make sure that Make is only ever a convenience method for things 
that can otherwise be easily done from the command-line (e.g. “go test ./…”). 
Make then becomes a) a convenience for running basic things (e.g. make test, 
make cover, make docker-test-race, that sort of thing) and b) a method for 
making sure our developers are running the same commands locally that the CI 
process does (don’t underestimate the importance of that for avoiding 
difficult-to-diagnose problems).

It’s also nothing you can’t do with plain shell scripts, but you’ll find 
yourself reinventing a lot of things that Make does for you quite nicely out of 
the box, like default parameters, list handling, target dependencies, etc.


- Dave

-- 
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/6FC5892A-BB6A-4A59-93CC-942C2AA5105F%40gmail.com.

Re: [go-nuts] Makefiles for Go Programs

[David Riley]

On Aug 22, 2021, at 23:11, jlfo...@berkeley.edu  wrote:
> 
> 
> I've noticed that few, if any, Go programs use Makefiles. Is that because the 
> overhead of using make is greater than the overhead of just always compiling 
> and linking everything?
> One piece of evidence for this is that the Go compiler leaves no artifacts, 
> like object files, so as is make wouldn't fit into the current build method.

I use Makefiles in our own internal projects because it allows me to establish 
a lot of good tooling around them, especially for repos which build a lot of 
binaries, Dockerize them, etc. It’s quite useful, despite the lack of 
intermediate files which Make tends to rely on to determine whether to rebuild 
things. Among other things, Make deals a lot better with lists of files and the 
concept of prerequisite steps than e.g. Bourne shell, and the Make package is 
actually considerably smaller than Bash in most tiny distros like Alpine, which 
is a consideration for Dockerfiles.

Unfortunately, to make Make worth the effort in Go projects, you need to 
understand it, otherwise you’ll just wind up with a lot of independent targets 
with a lot of repetitive code. Many developers these days (especially newer 
ones) have never been exposed to Make other than just running it and aren’t 
aware of what it can do, and so tend not to understand why you might not use it 
instead of e.g. Bash (they also tend not to understand why it might not be a 
good idea to use Bashisms instead of vanilla Bourne shell, but that’s a 
conversation for another time).

Basically, Make can make your Go projects a lot more intuitive to build, 
especially when it comes to things like default flags and consistency with CI, 
but you do have to put some effort into it, and you have to get people over the 
“Make is hard” mindset or they will “fix” your project by getting rid of it, 
IME.

FWIW, our default “make test” target generally just does “go test -race ./…”, 
with some optional coverage arguments spliced in when you “make cover”. “make 
cover-report” is where Make starts to shine; there’s a file prerequisite rule 
defined for the coverage file as well as for the HTML coverage report, and 
“make cover-report” just says to build the report file and Make’s dependency 
resolution magically takes care of the rest. It’s actually a pretty good basic 
demonstration of capabilities that used to be considered standard knowledge.


- Dave

-- 
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/052168C4-EFE0-49AA-AEDC-8B3557025C81%40gmail.com.

Re: [go-nuts] Why isn't go more popular?

[David Riley]

On Aug 5, 2021, at 10:27 PM, Ian Lance Taylor  wrote:
> 
> On Thu, Aug 5, 2021 at 7:20 PM Santi Ferra
>  wrote:
>> 
>> When you see the ranking of the most liked programming languages, go is near 
>> c++, a really "hated app". But since is efficient and produces really clean 
>> code, why no wants like it ?
> 
> What rankings are you looking at?

Seconded.  I would question those rankings, at least for code that's used for 
forward-looking purposes; in my experience, Go is rapidly replacing Java and in 
a number of cases Python for backend applications, and it has a lot of 
first-party support for things like API clients, telemetry, etc. that comes 
before those languages in many cases as well.

I feel like most people who dislike Go generally haven't used it. Having used 
it quite a bit, there are things I don't like a lot about it, but they're 
things that I feel like I can easily overlook given all the things it improves 
for me.  Those are the things people who haven't really given it much use tend 
to seize on, in my experience (e.g. "Go doesn't have generics", "Go doesn't 
really have a good way to make an iterator", etc.).

Rankings aren't generally very useful because they try to turn a massive vector 
quantity into a scalar for everyone's purposes, when in reality different 
people put different weights on things.  It's much more likely that you're 
seeing the effects of "which language is most used", and Go is a lot younger 
than most of the other languages in those rankings.


- Dave

-- 
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/92091078-2F36-4606-B3ED-BBA74957E17B%40gmail.com.

Re: [go-nuts] Changing wall clock in unit test

[David Finkel]

On Fri, Jul 30, 2021 at 12:13 AM Carl  wrote:

> Hi,
>
> Is there a way to write a unit test that simulates a change in the wall
> clock for a time.Time value?
>

I use a combination of two approaches to simulate the passage of time
(often both work together):

   - have functions a `now` argument so the caller supplies the timestamp
   (this avoids timestamp-skew for cases where the timestamps should be close
   together anyway)
   - Use a package like https://github.com/vimeo/go-clocks (
   https://pkg.go.dev/github.com/vimeo/go-clocks) to use a real clock in
   production, but have a fake clock you can advance/set however you want
   without impinging on the main code

Full disclosure: I wrote github.com/vimeo/go-clocks, so I might be a bit
biased -- it is based on one of Google's internal packages for C++, though.

One additional benefit of using a fake clock is that it allows for
fine-grained synchronization between tests and code if you're sleeping in
goroutines, as the fake clock in go-clocks has methods for awaiting a
certain number of sleepers, etc.


>
> Cheers,
> Carl
>
> --
> 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/f306417d-46f9-4ccd-8e7c-69a1dbd14969n%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/CANrC0Bj6KMLQ-erdAB0dfJC1XSNw%2BgWfx43pqSAZ8W4efpnZQQ%40mail.gmail.com.

Re: [go-nuts] Go and GPUs

[David Riley]

On Jun 25, 2021, at 10:23 PM, Robert Engels  wrote:
> 
> There is also a LOT of support for Java and CUDA/OpenCL. You can essentially 
> reimplement them Java portion in Go. There are multiple open source projects 
> in this area. 
> 
> Might be a lot easier than starting from scratch. 

Yes, CGo is going to be similar to JNI in this context.


- Dave

-- 
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/70F2856D-0640-490F-BFAC-366A17A991AD%40gmail.com.

Re: [go-nuts] Go and GPUs

[David Riley]

On Jun 25, 2021, at 1:32 PM, Robert Engels  wrote:
> 
> Why not develop a Go <> CUDA binding using CGo?

This (ditto for OpenCL, Vulkan, etc) is more likely the path you'll have to go 
down.  Generally all of these interfaces rely on pretty massive libraries from 
NVIDIA, AMD, Intel, etc. which are only going to have a C ABI because basically 
every other language on the planet uses the C ABI (with exceptions for 
interpreted languages like Java or Pythons, which contain adaptations like JNI 
to the C ABI, whose purpose is fulfilled by CGo here).

You're not going to get a non-CGo interface to any mainstream GPU programming 
interface unless you happen to have enough money to convince Intel, AMD and 
NVIDIA to go to the trouble of writing them, at which point you will also be 
involving massive industry committees. You don't want that.

CGo is an acceptable tradeoff here, IMO, because the overhead of bus 
transactions to the GPU is likely to be much worse than any overhead CGo adds 
unless you're doing something terribly wrong. You want large, infrequent 
transactions that you can queue up, otherwise you'll eat up all your time 
waiting for transactions anyway.

Consider that plenty of high performance GPU computation is done using plain 
Python interfaced to CUDA. The interface to the library isn't what matters, 
it's what you do with it.

These interfaces already exist in various states of maintenance, FWIW:

https://github.com/gorgonia/cu (last updated a year or so ago)
https://github.com/rafaelescrich/cuda-go (last updated about half a year ago)


- Dave

-- 
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/7786F4DE-CF75-471B-9709-EE1C9A4DAF1D%40gmail.com.

Re: [go-nuts] Recomended GOPROXY (or not) for Open Source projects?

[David Finkel]

On Fri, Jun 25, 2021 at 1:23 PM josvazg  wrote:

> When working on internal company projects, it makes sense to use a company
> wide GO Proxy assuring that all go dependency code is available and
> immutable. But when you move to an Open Source project, you cannot longer
> use such private proxy.
>
> I wonder what is the best practice recommendation for Open Source projects.
>
> I can't comment about whether anything specifically is a "best practice",
but here are my thoughts:


> For instance, reading about https://proxy.golang.org/ is says:
> > Why did a previously available module become unavailable in the mirror?
>
> > proxy.golang.org  does not save all modules
> forever.
>
> Which means, your project may *not compile* anymore if someone pulls one
> of your dependencies and proxy.golang.org decides to drop it.
>
The next line in that FAQ section mentions specific reasons why
proxy.golang.org wouldn't persist a module version in its cache. (e.g.
licences it doesn't recognize as letting it keep/distribute copies of the
code)

This seems like a non-issue if you are careful about your dependencies (and
specifically, their licenses (which seems to be easy to tell now that
pkg.go.dev will flag unrecognized licenses)).

> When you read that, you may decide to just track the vendor/ folder in
> your repo and forget about proxies for OSS projects.
>
> What is the recommendation from the Go community about this?
>
> - Are there public go proxies can be used for OSS projects ensuring you
> will never lose any dependency?
>
> - Is https://goproxy.io/ giving such guarantee maybe?
>
> - Should we just vendor and forget about Go-Proxies for Open Source?
>
Now that Go Modules is relatively mature, please don't use vendoring in
open source projects unless you have a really good reason.
Vendoring makes it impossible for the rest of us to tell whether there are
modifications to those dependencies and blows up your repo's size at the
same time. (at least without some really complicated diffing)

> Thanks,
>
> Jose
>
> --
> 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/47c445ca-884d-49b5-8357-aeae8802e937n%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/CANrC0BizsWRjdZSKXBqCKikhHcNbyWpP9d_pnr7odK3YQq_xgA%40mail.gmail.com.

Re: [go-nuts] Golang language specification Document: Composite Literals example is not understandable

[David Riley]

On Jun 22, 2021, at 12:42, Axel Wagner  wrote:
> 
> 
> Oh and also:
> 
>> Likewise, I think this only works for array literals; I don’t think (though 
>> again have not tried it) that you can declare slice literals with only 
>> selected members initialized.
> 
> Works fine too: https://play.golang.org/p/ANw54ShkTvY :)

Yeah, I re-read the doc and realized my assumption was erroneous shortly after 
I sent the last one… this is why I put the disclaimer on things I have not 
tried yet. :-)


- Dave

-- 
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/C0E9CFB3-0B02-49A8-8EE0-8CB9CA19681E%40gmail.com.

Re: [go-nuts] Golang language specification Document: Composite Literals example is not understandable

[David Riley]

On Jun 22, 2021, at 11:39, Vaibhav Maurya  wrote:
> 
> Hi,
> 
> Please help me to understand the following syntax mentioned in the Golang 
> language specification document.
> 
> https://golang.org/ref/spec#Composite_literals
> 
> following is the search string for CTRL + F
> // vowels[ch] is true if ch is a vowel \
> 
> Following declaration and initialization is confusing.
> vowels := [128]bool{'a': true, 'e': true, 'i': true, 'o': true, 'u': true, 
> 'y': true}
> 
> Here one can see the vowels is an array. Where in the array initialization 
> syntax, there is a key value pair. I believe bool is the primitive type, so 
> the array values should be either true or false.
> Why there are key value pair separated by colon in the initialization.

In this case, it is because the single quotes create a literal rune, which 
ultimately is an integer; this is creating an array 128 wide of bools, of which 
only the values indexed by those character values are initialized (everything 
else is the zero value, or false).

This example only works for characters in the 7-bit ASCII subset of UTF-8; if 
you were to put other characters in which had rune values greater than 127, 
this would break (I assume with a runtime rather than a compiler error, but I 
haven’t tried it). Likewise, I think this only works for array literals; I 
don’t think (though again have not tried it) that you can declare slice 
literals with only selected members initialized.


- Dave

-- 
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/2564C639-E055-4DD9-97A2-9B6061F83006%40gmail.com.

[go-nuts] Go 1.16.5 and Go 1.15.13 are released

[David Chase]

Hello gophers,

We have just released Go versions 1.16.5 and 1.15.13, minor point releases.

These minor releases include security fixes according to the new security
policy (#44918 <https://github.com/golang/go/issues/44918>).

The SetString and UnmarshalText methods of math/big.Rat
<https://pkg.go.dev/math/big#Rat> may cause a panic or an unrecoverable
fatal error if passed inputs with very large exponents.
This is issue #45910 <https://github.com/golang/go/issues/44910> and
CVE-2021-33198.

Thanks to the OSS-Fuzz project for discovering this issue and to Emmanuel
Odeke for reporting it.

ReverseProxy in net/http/httputil <https://pkg.go.dev/net/http/httputil> could
be made to forward certain hop-by-hop headers, including Connection. In
case the target of the ReverseProxy was itself a reverse proxy, this would
let an attacker drop arbitrary headers, including those set by the
ReverseProxy.Director.
This is issue #46313 <https://github.com/golang/go/issues/46313> and
CVE-2021-33197.

Thanks to Mattias Grenfeldt (https://grenfeldt.dev) and Asta Olofsson for
reporting this issue.

The LookupCNAME, LookupSRV, LookupMX, LookupNS, and LookupAddr functions in
net <https://pkg.go.dev/net>, and their respective methods on the Resolver
<https://pkg.go.dev/net#Resolver> type may return arbitrary values
retrieved from DNS which do not follow the established RFC 1035
<https://datatracker.ietf.org/doc/html/rfc1035>rules for domain names. If
these names are used without further sanitization, for instance unsafely
included in HTML, they may allow for injection of unexpected content. Note
that LookupTXT may still return arbitrary values that could require
sanitization before further use.
This is issue #46241 <https://github.com/golang/go/issues/46241> and
CVE-2021-33195.

Thanks to Philipp Jeitner and Haya Shulman from Fraunhofer SIT for
reporting this issue.

The NewReader and OpenReader functions in archive/zip
<https://pkg.go.dev/archive/zip> can cause a panic or an unrecoverable
fatal error when reading an archive that claims to contain a large number
of files, regardless of its actual size.
This is issue #46242  <https://github.com/golang/go/issues/46242>and
CVE-2021-33196.

Thanks to the OSS-Fuzz project for discovering this issue and to Emmanuel
Odeke for reporting it.

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.16.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.16.5" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
David and Carlos for the Go team

-- 
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/CABE21dZg1z%3D9HP_5rK2GvjA9FzXEZFfyPnZi-FG2qHgj-Zsn0A%40mail.gmail.com.

Re: [go-nuts] Go: pointer bit stealing technique

[David Riley]

On May 6, 2021, at 7:16 AM, Vitaly Isaev  wrote:
> 
> There is no similar type in C/C++/Go stdlib, but at least in C++ it's 
> possible to model it using bit stealing approach (see C++ example). On x86_64 
> arch only 48 bits of 64 bits are actually used, so one can store arbitrary 
> data in the remaining 16 bits, and work with the whole pointer and the data 
> atomically.

I would strongly recommend that you not do this, because this has a nasty way 
of breaking a LOT of things in the future.  The original Macintosh system 
software and ROMs used this "clever" technique almost exactly, because the 
68000 only had a 24-bit address bus.  When the 68020 came out and people wanted 
to use more than 16 MB of address space, it created BIG problems which took 
many years to resolve (and many things were not completely resolved until Apple 
moved to the PowerPC).

History is littered with examples of why you should not do naughty things with 
"unused" pointer bits (see also ARM's Thumb instruction set, which used the 
unused LSB of the instruction counter to signify Thumb mode, causing headaches 
for compiler, debugger and disassembler writers to this day).


- Dave

-- 
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/CAF81D0A-9AD0-4412-9013-76FEB6C13C27%40gmail.com.

Re: [go-nuts] Getting a Go executable(hugo) to run Intel Galileo/Quark

[David Markey]

>
> galileo:/home/galileo# free
>
>   totalusedfree  shared  buff/cache
> available
>
> Mem: 209592   20612   34620  76  154360
> 180376
>
> Swap:   1048572   0 1048572
>
> galileo:/home/galileo# ./hugo
>
> panic: runtime error: invalid memory address or nil pointer dereference
>
> [signal SIGSEGV: segmentation violation code=0x1 addr=0xc pc=0xb76f5df2]
>
>
> goroutine 1 [running]:
>
> galileo:/home/galileo# ldd ./hugo
>
> /lib/ld-musl-i386.so.1 (0xb7f1a000)
>
> libgo.so.16 => /usr/lib/libgo.so.16 (0xb3a9e000)
>
> libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb3a8)
>
> libc.musl-x86.so.1 => /lib/ld-musl-i386.so.1 (0xb7f1a000)
>
> libucontext.so.1 => /lib/libucontext.so.1 (0xb3a7b000)
>
> galileo:/home/galileo# file ./hugo
>
> ./hugo: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV),
> dynamically linked, interpreter /lib/ld-musl-i386.so.1, with debug_info,
> not stripped
>

Good suggestion, alas no breakthrough. Will investigate tinygo, This one
"feels" close..though, spends 12 seconds doing *something* - although on a
CPU this slow it might actually just be loading the binary into memory.

galileo:/home/galileo# time ./hugo
>
> panic: runtime error: invalid memory address or nil pointer dereference
>
> [signal SIGSEGV: segmentation violation code=0x1 addr=0xc pc=0xb7700df2]
>
>
> goroutine 1 [running]:
>
> Command exited with non-zero status 2
>
> real 0m 12.62s
>
> user 0m 11.52s
>
> sys 0m 0.99s
>








On Fri, 16 Apr 2021 at 16:46, Brian Candler  wrote:

> Can you add a swapfile?  That could rule out low RAM as the problem, even
> if it's very inefficient.
>
> Aside: 127MB does sound like a very large binary, compared to what the
> standard go toolchain produces.   The official hugo amd64 binary is about
> 44MB:
>
> $ tar -tvzf hugo_0.82.0_Linux-64bit.tar.gz
> -rw-r--r--  0 root   root11357 21 Mar 17:17 LICENSE
> -rw-r--r--  0 root   root12345 21 Mar 17:17 README.md
> -rwxr-xr-x  0 root   root 44568576 21 Mar 17:51 hugo
>
> And k3s (a complete kubernetes distribution) is around 55MB.
>
> Given the limited target system, maybe tinygo is worth playing with -
> although I have no idea whether hugo will work with the subset of language
> features it provides.
>
> --
> 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/475a30e7-8404-4af4-8ae2-3aff0dcc6a0en%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/CANXrN%3D3wf_Mxof-Pj%2BD6WJJAG33rm8%2B%2BqPrtjDk3Vsq-QaP%3DhA%40mail.gmail.com.

Re: [go-nuts] Getting a Go executable(hugo) to run Intel Galileo/Quark

[David Markey]

Thanks for the reply!

After recompiling gcc-go and libgo with the " -Wa,-momit-lock-prefix=yes
-march=i586" flags and compiling hugo with:

go build  -gccgoflags="-Wa,-momit-lock-prefix=yes -march=i586"

Still getting an error, but a more terse version:

./hugo
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0xc pc=0xb768bdf2]

goroutine 1 [running]:

The same executable still works on my VM (although blows up with more than
1 core on the VM, as one might expect)

Any more pointers? This is just a play project, if it doesn't work it's not
the end of the world.




On Thu, 15 Apr 2021 at 22:20, Ian Lance Taylor  wrote:

> On Thu, Apr 15, 2021 at 1:11 PM David Markey  wrote:
> >
> > I'm trying to get hugo to work on my Alpine distro that's running on my
> Intel gallileo(Quark CPU).
> >
> > I've overcome a few hurdles already.
> >
> > This CPU Doesn't have MMX so gcc-go was needed to compile hugo into a
> binary (in a virtual machine)
> >
> > But after copying the hugo binary to the galileo Hugo doesn't work. I
> get the following error:
> >
> > fatal error: unexpected signal during runtime execution [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x44 pc=0xb7658e62] goroutine 1
> [running]: runtime.dopanic_m :0 runtime.throw :0 runtime.sigpanic :0
> runtime.sigtrampgo :0 runtime.sigtramp :0 :0 goroutine 4 [select]:
> go.x2eopencensus.x2eio..z2fstats..z2fview.worker.start
> /root/go/pkg/mod/go.opencensus.io@v0.22.0/stats/view/worker.go:154
> created by
> go.x2eopencensus.x2eio..z2fstats..z2fview.go.x2eopencensus.x2eio..z2fstats..z2fview..init0
> /root/go/pkg/mod/go.opencensus.io@v0.22.0/stats/view/worker.go:32 +0x17a
> >
> > This could be:
> >
> > Galileo has 256MB of ram only, The executable is 127MB, perhaps there
> simply isn't enough memory?
>
> This particular error looks like a nil dereference.  That would only
> be caused by insufficient memory if the Go code calls C code that
> calls malloc and doesn't check for a return value of NULL.
>
>
> > Quark has a well known bug.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575%22 that means it
> mishandles LOCK instructions and causes a segfault.
> >
> > On a normal C toolchain, the assembler can strip the LOCK operation
> using "-Xassembler '-momit-lock-prefix=yes'" CFLAG (Galileo is single core
> so it's not needed)
> >
> > However I'm not sure what the equivalent would be on a go build
> toolchain, perhaps it's simply not possible?
>
> Since you are using gccgo, the same option should work.  But you might
> possibly have to recompile the Go library with that option.
>
> Ian
>

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

[go-nuts] Getting a Go executable(hugo) to run Intel Galileo/Quark

[David Markey]

I'm trying to get hugo to work on my Alpine distro that's running on my 
Intel gallileo(Quark CPU).

I've overcome a few hurdles already.

This CPU Doesn't have MMX so gcc-go was needed to compile hugo into a 
binary (in a virtual machine)

But after copying the hugo binary to the galileo Hugo doesn't work. I get 
the following error:
fatal error: unexpected signal during runtime execution [signal SIGSEGV: 
segmentation violation code=0x1 addr=0x44 pc=0xb7658e62] goroutine 1 
[running]: runtime.dopanic_m :0 runtime.throw :0 runtime.sigpanic :0 
runtime.sigtrampgo :0 runtime.sigtramp :0 :0 goroutine 4 [select]: 
go.x2eopencensus.x2eio..z2fstats..z2fview.worker.start 
/root/go/pkg/mod/go.opencensus.io@v0.22.0/stats/view/worker.go:154 created 
by 
go.x2eopencensus.x2eio..z2fstats..z2fview.go.x2eopencensus.x2eio..z2fstats..z2fview..init0
 
/root/go/pkg/mod/go.opencensus.io@v0.22.0/stats/view/worker.go:32 +0x17a 

This could be:

   1. Galileo has 256MB of ram only, The executable is 127MB, perhaps there 
   simply isn't enough memory?
   2. Quark has a well known bug. 
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575%22 that means 
   it mishandles LOCK instructions and causes a segfault.

On a normal C toolchain, the assembler can strip the LOCK operation using 
"-Xassembler '-momit-lock-prefix=yes'" CFLAG (Galileo is single core so 
it's not needed)

However I'm not sure what the equivalent would be on a go build toolchain, 
perhaps it's simply not possible?

The compiled binary works perfectly in the virtual machine.

-- 
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/759a4185-f868-4fa9-a35a-4aa7e8c569dbn%40googlegroups.com.

[go-nuts] Re: HTTP routes in different Packages

[David Fornazier]

Hello!

You could create in your packages a function that receives  a  
*http.ServeMux, by this reference you can configure you're path an function 
related.

Example:
"example.go"

func FooPath(mux *http.ServeMux) {
mux.HandleFunc("/foo", exampleFoo)
}

func exampleFoo(w http.Res..., r *http.Req) {
json.NewEncoder(w).Encode("Hi there!")
}

-
...
-

"routes.go"

fun main() {
//router
mux := http.NewServeMux()

//config the paths
example.FooPath(mux)

s := {
Addr:   "localhost:1324",
Handler:mux,
ReadTimeout:10 * time.Second,
WriteTimeout:   10 * time.Second,
}
log.Fatal(s.ListenAndServe())
}

Em terça-feira, 6 de abril de 2021 às 11:30:02 UTC-3, Van Fury escreveu:

>
> HI,
>
> I have the following settings in my REST API program packages:
>
> In "routers.go"
>
> type Route struct {
> Namestring
> Method  string
> Pattern string
> HandlerFunc http.HandlerFunc
> }
>
> var Router = NewRouter()
>
> type Routes []Route
>
> func NewRouter() *mux.Router {
> router := mux.NewRouter().StrictSlash(true)
> for _, route := range routes {
> var handler http.Handler
> handler = route.HandlerFunc
>
> router.
> Methods(route.Method).
> Path(route.Pattern).
> Name(route.Name).
> Handler(handler)
> }
>
> return router
> }
>
> func Index(w http.ResponseWriter, r *http.Request) {
> fmt.Fprintf(w, "Hello World!")
> }
>
> var routes = Routes{
>
> Route{
> "UserData",
> strings.ToUpper("Get"),
> "/{id}/user-data",
> UserData,
> },
>
> Route{
> "UserData",
> strings.ToUpper("Post"),
> "/{id}/user-data",
> UserData,
> },
>
> Route{
> "ExampleData",
> strings.ToUpper("Post"),
> "/{id}/example-data",
> ExampleData,
> },
>
> Route{
> "ExampleData",
> strings.ToUpper("Get"),
> "/{id}/example-data",
> ExampleData,
> },
>
> }
>
> In "main.go"
>
> func main(){
>
> var LISTENING_ADDR = GetListeningAddress()
> ...
>
> server := NewServer(LISTENING_ADDR)
>
>  go func() {
> err := server.ListenAndServe() // use if http
> if err != nil && err != http.ErrServerClosed {
> logger.Log.Errorf("Could not listen on %s: %v\n", 
> LISTENING_ADDR, err)
> os.Exit(0)
> }
> }()
>
> }
>
> // NewServer - Create a new server
> func NewServer(LISTENING_ADDR string) *http.Server {
>
> return {
> Addr: LISTENING_ADDR,
> Handler:  Router,
> TLSConfig:TLSConfig(),
> ReadTimeout:  5 * time.Second,
> WriteTimeout: 10 * time.Second,
> IdleTimeout:  120 * time.Second,
> }
> }
>
> I have two other packages, example.go and user.go which contain the 
> handler functions.
>
> "example.go"
> func ExampleDataPost(w http.Res..., r *http.Req) {
> ...
> }
>
> func ExampleDataGet(w http.Res..., r *http.Req) {
> ...
> }
>
> Also In "user.go" is
> func UserDataPost(w http.Res..., r *http.Req) {
> ...
> }
>
> func UserDataGet(w http.Res..., r *http.Req) {
> ...
> }
>
> I would like to move their routes in their respective packages.
> I have for example added to "user.go"  what is shown below and the same 
> for "example.go" but my problem is how to call the variables (group 
> routers) "UserNewRouter ", "ExampleNewRouter" in their respective routers 
> in the main.go or the "NewServer". 
> Any help on how to go about this?
>
> "user.go"
>
> func UserDataPost(w http.Res..., r *http.Req) {
> ...
> }
>
> func UserDataGet(w http.Res..., r *http.Req) {
> ...
> }
>
> type Route struct {
> Namestring
> Method  string
> Pattern string
> HandlerFunc http.HandlerFunc
> }
>
> var UserNewRouter = NewRouter()
>
> type Routes []Route
>
> func NewRouter() *mux.Router {
> router := mux.NewRouter().StrictSlash(true)
> for _, route := range routes {
> var handler http.Handler
> handler = route.HandlerFunc
>
> router.
> Methods(route.Method).
> Path(route.Pattern).
> Name(route.Name).
> Handler(handler)
> }
>
> return router
> }
>
> var routes = Routes{
>
> Route{
> "UserDataGet",
> strings.ToUpper("Get"),
> "/{id}/user-data",
> UserDataGet,
> },
>
> Route{
> "UserDataPost",
> strings.ToUpper("Post"),
> "/{id}/user-data",
> UserDataPost,
> },
>
> }
>
>
> "example.go"
> func ExampleDataPost(w http.Res..., r *http.Req) {
> ...
> }
>
> func ExampleDataGet(w http.Res..., r *http.Req) {
> ...
> }
>  
> type Route struct {
> Namestring
> Method  string
> Pattern string
> HandlerFunc http.HandlerFunc
> }
>
> var ExampleNewRouter = NewRouter()
>
> type Routes []Route
>
> 

[go-nuts] Re: nice user survey re Go-lang

[David Skinner]

Thank you for sharing. 

I think the most important things to learn from this survey are the 
problems identified.

For example, This is an important opportunity for new users if they have 
not used the debug tools to take careful notes and create precise 
documentation for others.

On Wednesday, March 17, 2021 at 11:16:30 AM UTC-5 Carla Pfaff wrote:

> It's a nice survey indeed. This is the original source of the article: 
> https://blog.golang.org/survey2020-results
>

-- 
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/5b5e9336-cd91-4249-80a8-cdb169c66ab4n%40googlegroups.com.

Re: [go-nuts] No generic, part -2

[David Skinner]

;>
>>>> Since pro-generics ppl here are struggling to provide any evidence of
>>>> existence of open and public discussion on the topic of dropping generics,
>>>> I will do it myself.
>>>>
>>>> Here is it:
>>>> https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/-EZp3YSeBQAJ
>>>>
>>>>
>>>>
>>>> --
>>>> 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/d8b96595-effe-4eed-898d-1c4e183189dbn%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/golang-nuts/d8b96595-effe-4eed-898d-1c4e183189dbn%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/lC9Z9VZXPdM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu14%2B2YuGzaOfuazhAL3D62B1Gd3kjhmnV2U1sY_KqLdXA%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu14%2B2YuGzaOfuazhAL3D62B1Gd3kjhmnV2U1sY_KqLdXA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


-- 

Respectfully submitted,
David Lynn Skinner
Secretary, Davsk Ltd Co
<http://stackoverflow.com/users/3886366/david-skinner>
<http://github.com/ComalDave/> <http://facebook.com/david.lynn.skinner/>
<http://www.instagram.com/david.lynn.skinner/>
<http://www.linkedin.com/in/david-l-skinner/>
<http://twitter.com/SkinnerDavidL> <http://youtube.com/c/DavidSkinnerDavsk>
<http://www.pinterest.com/skinnerdavid/>

IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only. If you have received
this email by mistake, please notify the sender immediately and do not
disclose the contents to anyone or make copies thereof.
[image: App Green Footer Image] Be like me, be Carbon free - don't print
this and save a tree

"Look deep into nature, and then you will understand everything better." -
Albert Einstein.
 <https://conf.davsk.net/david> [image: App Video Meeting Image]
<https://conf.davsk.net/david> Meet me on Zoom
<https://conf.davsk.net/david>  <https://conf.davsk.net/david>
Check out my blog [image: arrow] <https://blog.davsk.net>

-- 
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/CAGe8nGEhwW5zNcp2gZ9F0RBSf5-4G3QWB3yya2aBzMGeBq4zuQ%40mail.gmail.com.