Re: [go-nuts] net/http: no Client API to close server connection based on Response #21978

['Sean Liao' via golang-nuts]

since you already know the server is problematic, you could just set Close
on the original request.

On Tue, Apr 2, 2024, 15:29 Jim Minter  wrote:

> Hello,
>
> I was wondering if anyone had any ideas about
> https://github.com/golang/go/issues/21978 ("net/http: no Client API to
> close server connection based on Response") -- it's an old issue, but it's
> something that's biting me currently and I can't see a neat way to solve it.
>
> As an HTTP client, I'm hitting a case where some HTTP server instance
> behind a load balancer breaks and starts returning 500s (FWIW with no body)
> and without the "Connection: close" header.  I retry, but I end up reusing
> the same TCP connection to the same broken HTTP instance, so I never hit a
> different backend server and my retry policy is basically useless.
>
> Obviously I need to get the server owner to fix its behavior, but it would
> be great if, as a client, there were a way to get net/http not to reuse the
> connection further, in order to be less beholden to the server's behavior.
>
> This happens with both HTTP/1.1 and HTTP/2.
>
> If appropriate, I could live with the request to close the connection
> racing with other new requests to the same endpoint.  Getting to the point
> where 2 or 3 requests fail and then the connection is closed is way better
> than having requests fail ad infinitum.
>
> http.Transport.CloseIdleConnections() doesn't solve the problem well (a)
> because it's a big hammer, and (b) because there's no guarantee that the
> connection is idle when CloseIdleConnections() is called.
>
> FWIW I can see in `func (pc *persistConn) readLoop()` there's the
> following test:
>
> ```go
> if resp.Close || rc.req.Close || resp.StatusCode <= 199 || bodyWritable {
> // Don't do keep-alive on error if either party requested a close
> // or we get an unexpected informational (1xx) response.
> // StatusCode 100 is already handled above.
> alive = false
> }
> ```
>
> I imagine that extending that to `if resp.Close || rc.req.Close ||
> resp.StatusCode <= 199 || bodyWritable || resp.StatusCode >= 500 {` might
> probably help this specific case, but I imagine that's an unacceptably
> large behavior change for the rest of the world.
>
> I'm not sure how else this could be done.  Does anyone have any thoughts?
>
> Many thanks for the help,
>
> Jim
>
> --
> 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/34d597cf-a84c-48eb-b555-537a8768f468n%40googlegroups.com
> 
> .
>
- sean

-- 
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/CAGabyPoPE2VQOj8dwabc_1LQC%2BiZbqBsLNJpfwi7HQ3%2BjgS%2BwA%40mail.gmail.com.

Re: [go-nuts] Failed to compile a generic code using embedded struct

['Sean Liao' via golang-nuts]

see
https://go.dev/issue/51183

- sean

On Mon, Feb 26, 2024, 15:44 Albert Widiatmoko 
wrote:

> Hi Go community,
>
> I was playing with Go generics and writing some codes, but I faced some
> problems. I want to ask questions and help from the community if possible.
> Below, I am trying to build a generic struct via a method through another
> generic struct.
>
> Here's the link to Go Playground: https://go.dev/play/p/Q0zOJUePkmR
>
> ---
>
> package main
>
> var _ I = (*A)(nil)
>
> type I interface {
> String() string
> }
>
> type A struct {
> str string
> }
>
> func (a A) String() string {
> return a.str
> }
>
> type AE[T, V I] struct {
> T1 T
> T2 V
> }
>
> // func (AE[T, V]) String() string {
> // return "test"
> // }
>
> type Test[T, V A] struct{}
>
> func (t Test[T, V]) S() AE[T, V] {
> return AE[T, V]{}
> }
>
> func main() {}
>
> ---
>
> I expected the program to run, but then I got an error:
>
> T does not satisfy I (missing method String)
>
> I a bit confused because A implements I interface. I think this must be
> because I missed something with the Go generics.
>
> 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/1ab4599e-1f6c-493e-85e7-11d35e77012bn%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/CAGabyPpZz_MJKRqNKQyNCQDj2ya%2BeTYZ0k9RdrKX_TT0m%2BfFBQ%40mail.gmail.com.

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

['Sean Liao' via golang-nuts]

https://go.dev/issue/21335

- sean

On Wed, Feb 21, 2024, 00:36 Sam Vilain  wrote:

> Alright, well thanks for your input.
>
> I do think these questions can be answered; exploring the use cases in a
> proposal format should hopefully show that the impact of closures would not
> normally be an issue.  Possibly the worst case is if you had a library to
> some external service, and at some low layer you're using a closure, well
> you might need to refactor that if you wanted to add cross–service tracing
> support.  But to be honest, it's probably better that the state you're
> depending on is captured in a struct instead of being scattered about
> loosely in a scope as with a closure.  And the common practice in Go is to
> return types that satisfy interfaces, not function references that you
> blind call.
>
> I think I will submit a proposal, but please don't take that to imply that
> I think you're "wrong, or mistaken".  Your concerns are legitimate and the
> proposal should answer them cleanly.  In the proposal format, hopefully the
> "litigation", or more exploration of possible uses and abuses of the
> system, along with performance concerns, can be addressed.  I don't want to
> be dismissive of them, I just want to understand them.
>
> I had a brief look on the Golang issues in Github and could not find any
> prior proposals along this line using "context" and "dynamic scope" as
> search terms, so I'll submit this as a "new" proposal for now.
>
> Thanks again, and truly—thanks for responding, >100% better than people
> who just rolled eyes and marked thread as read.
>
> Cheers,
> Sam
> On 2/20/24 3:35 PM, Axel Wagner wrote:
>
> If I may quote myself:
>
> > And no matter which choice you make for the language - it means that if
> the programmers wanted the other, they'd have to jump through annoying
> hoops and get confusing and hard to debug problems.
>
> Having a mechanism to get one or the other semantic doesn't change the
> fact that it's easy to choose wrongly by accident, as long as the effect is
> implicit. In fact, the mechanism you propose (AIUI) seems extra confusing:
> Having a function value sometimes create a new dynamic scope and sometimes
> not, is weird and seems like a recipe for frustration.
>
> But really, convincing me isn't really the point, which is why I'm not
> super invested in litigating this (otherwise I might try to come up with
> realistic examples, for instance. Or explain further why I'm still not sure
> that this can be implemented efficiently). I'm just re-stating what, in the
> past, where the reasons why things like this have been rejected. In order
> to predict what I would consider a likely outcome of a proposal like this.
>
> If you think I am wrong or misunderstanding you, you can always file a
> proposal to get a more official response.
>
> On Tue, Feb 20, 2024 at 8:18 PM Sam Vilain  wrote:
>
>> On 2/17/24 1:32 AM, Axel Wagner wrote:
>>
>> On Sat, Feb 17, 2024 at 2:09 AM Sam Vilain  wrote:
>>
>>> I would argue that the matter can be simply decided by choosing the
>>> *calling* stack, not the destination stack.
>>>
>>
>> I agree that this is *one choice*. But the point is, that *sometimes*
>> you'd want one and *sometimes* the other. And no matter which choice you
>> make for the language - it means that if the programmers wanted the other,
>> they'd have to jump through annoying hoops and get confusing and hard to
>> debug problems. So if you want to justify either choice, you have to make
>> an argument that it is so overwhelmingly more common what people would
>> want, that the cost of running into these problems is small enough to be
>> justified by the benefit.
>>
>> I think that's a hard case to make.
>>
>> Alex, I agree that there are cases where you might prefer one versus the
>> other.  However, you cut out the part of my reply where I pointed out it
>> was possible to choose semantics by either returning a closure (context is
>> the source stack) or a bound method (context is the destination stack).
>> Both of these values can be used interchangeably, as they have the same
>> type, func ..., and so the caller does not need to care whether the
>> function they are calling uses the calling context or the original
>> context.  Were you not convinced by the argument?
>>
>> Sam
>>
> --
> Sam
>
> --
> 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/aec85a83-9497-469c-8369-2c9e60d0ca05%40vilain.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, 

Re: [go-nuts] heap ballast

['Sean Liao' via golang-nuts]

The modern way to handle this is with GOMEMLIMIT
https://tip.golang.org/doc/gc-guide

- sean

On Mon, Feb 12, 2024 at 8:33 PM Mike Mitchell
 wrote:
>
> Purely for the sake of experiment (this is not a production environment 
> thing), I have tried to test out the Heap Ballast technique of reducing the 
> number of garbage collections with a small heap size, which I read about in a 
> blog post by Twitch, and I think I must have misinterpreted the use case of 
> such a technique. Can anyone help clarify for me? Thank you in advance
>
> My program consists of a webserver in the main func
>
>  http.ListenAndServe(":6000", http.DefaultServeMux)
>
> and I create a small ballast on my Digital Ocean 1 GB ram droplet (the twitch 
> blog post said they made a ballast of 10 <<30) but I did 10 << 20
>
>  ballast := make([]byte, 10<<20)
>
> I then sent a million requests to it
>
> ab -k -c 8 -n 100 "http://127.0.0.1:6000/;
>
> I also did the same without the heap ballast.
>
> The results (see attached images) surprised me because there was basically 
> the same number of garbage collections with and without the ballast. The only 
> difference the ballast seems to have made was that it increased HeapIdle 
> enormously.  How do people use Heap Ballast to reduce the number of GCs?
>
>  go version go1.21.1 linux/amd64
>
> I have read many people referring to this Heap Ballast technique as a way to 
> reduce the number of garbage collections with a small heap size. In fact, 
> this is what it says in the Twitch article
>
> At steady state, our application was triggering ~8–10 garbage collection (GC) 
> cycles a second (400–600 per minute).
>
> 30% of CPU cycles were being spent in function calls related to GC
>
> During traffic spikes the number of GC cycles would increase
>
> Our heap size on average was fairly small (<450Mib)
>
> At steady state, our application was triggering ~8–10 garbage collection (GC) 
> cycles a second (400–600 per minute).
>
> 30% of CPU cycles were being spent in function calls related to GC
>
> During traffic spikes the number of GC cycles would increase
>
> Our heap size on average was fairly small (<450Mib)
>
>
>
>
>
> --
> 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/7cee5b4e-24cc-4579-b5c9-62b93298c931n%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/CAGabyPpEHMKkOPC-5C_BiaUA2o4x%2BOq8wKz4QkbjqDNVUS2Avg%40mail.gmail.com.

Re: [go-nuts] Re: 1.22.0 ServeMux HandleFunc infinite loop

['Sean Liao' via golang-nuts]

I've filed it as https://go.dev/issue/65624

- sean

On Thu, Feb 8, 2024 at 6:58 PM Kyle Shannon  wrote:
>
> On 2/8/24 11:30, Jason Phillips wrote:
>
> Can you create a small self-contained program that reproduces the issue? The 
> following program returns 404 locally, as I'd expect, but does get killed in 
> the Go playground: https://go.dev/play/p/FigBLK8KrAK
>
> Perhaps a simpler reproduction that's runnable on the playground:
>
> https://go.dev/play/p/gmQGJsyNCT6
>
> This returns 301 with a Location of /x/.  Note the trailing slash in the mux 
> pattern, which was missing in your example.
>
>
> Perhaps there's an issue with the Playground networking implementation that's 
> incompatible with the 1.22 changes?
>
> On Thursday, February 8, 2024 at 12:03:46 PM UTC-5 Patricia Decker wrote:
>>
>> I haven't played around with it yet, but have you tried to separately 
>> register /something/ ?
>>
>> mux := http.NewServeMux()
>> mux.HandleFunc("/something/", func...)
>> mux.HandleFunc("/something/{id}/{$}", func...)
>>
>> On Wednesday, February 7, 2024 at 1:21:00 PM UTC-8 Péter Szarvas wrote:
>>>
>>> Hello,
>>>
>>> I noticed if you set up a route like /something/{id}/{$}, it results in an 
>>> infinite loop if I navigate to /someting/ (with the trailing slash). I got 
>>> a redirect to Location: /something/, and so on. Finally the page breaks 
>>> after multiple rounds.
>>>
>>> Example:
>>> mux := http.NewServeMux()
>>> mux.HandleFunc("/something/{id}/{$}", func...))
>>>
>>> Should I raise and issue or am I doing something wrong here?
>>>
>>> Thanks,
>>> Peter
>
> --
> 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/445d31e9-e9ce-407a-985c-ad448da9f786n%40googlegroups.com.
>
>
> --
> Kyle
>
> --
> 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/85cdc8ae-66cb-45e0-8ba5-b0380cee9df1%40pobox.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/CAGabyPryHf98e_OcB1ffC2ZdTQ_s88Vm-kG%2Bm1mtbNu1TCAwbA%40mail.gmail.com.

Re: [go-nuts] <-ctx.Done() panic

['Sean Liao' via golang-nuts]

maybe a bad custom context implementation in the chain

- sean

On Wed, Jan 3, 2024, 10:57 cheng dong  wrote:

> i have a program paniced with
>
> ```
> runtime.deferCallSave(0xc0313d56d8, 0xc0401839e8?)
> /home/ubuntu/go/go1.19.5/src/runtime/panic.go:796 +0x88
> fp=0xc0313d5618 sp=0xc0313d5608 pc=0x43b248
> runtime.runOpenDeferFrame(0xc02349b860?, 0xc0300967d0)
> /home/ubuntu/go/go1.19.5/src/runtime/panic.go:769 +0x1a5
> fp=0xc0313d5660 sp=0xc0313d5618 pc=0x43b065
> panic({0x344a800, 0xc03352c8d0})
> /home/ubuntu/go/go1.19.5/src/runtime/panic.go:884 +0x212
> fp=0xc0313d5720 sp=0xc0313d5660 pc=0x43b4b2
> runtime.panicdottypeE(0x6648f00, 0x32b77a0, 0x33adc40)
> /home/ubuntu/go/go1.19.5/src/runtime/iface.go:262 +0x6a
> fp=0xc0313d5740 sp=0xc0313d5720 pc=0x40cb2a
> context.(*cancelCtx).Done(0xc040183824?)
> /home/ubuntu/go/go1.19.5/src/context/context.go:361 +0x1d4
> fp=0xc0313d57c0 sp=0xc0313d5740 pc=0x512554
> ```
>
> however, this code just not match with go1.19.5 context/context.go:361. so
> i cant figure out what happened
>
> --
> 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/a1a18ea2-d2a2-4fe7-b906-ea4f8ea6cae7n%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/CAGabyPoxNXAUO5GreyfrpHMmQGR9c9%2BWJRrERx1MKHhtU7y2hQ%40mail.gmail.com.

Re: [go-nuts] https client 403 error

['Sean Liao' via golang-nuts]

see https://pkg.go.dev/net/http#Client.Jar

- sean

- sean


On Fri, Dec 29, 2023 at 6:53 PM vlya...@gmail.com  wrote:
>
> I use generic https client code to perform GET:
> tr := { TLSClientConfig: {InsecureSkipVerify: 
> true}, }
> client := { Transport: tr, }
> req, err := http.NewRequest("GET", url, nil)
> ...
> resp, err := client.Do(req)
>
> for most urls it works fine but for some (https://www.indeed.com/ for 
> example) i have the following error:
>
> Response status: 403 Forbidden Msg:
> Please enable cookies.
>
> Does my client have to get cookie from server? How can implement that?
> 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/80290cb7-6a87-4825-bfca-437c64d56596n%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/CAGabyPr3%3Dqd%2Brtd132%3DDN-1cFq_U5Nk_WGkzHye1ARdbLGOeQw%40mail.gmail.com.

Re: [go-nuts] Re: custom slog Handler which adds Attribute and WithGroup

['Sean Liao' via golang-nuts]

The slog API doesn't allow wrapping handlers this way. slog.Handlers hold
state for the current open group.
You'll need a full implementation of a handler to do this.

(Technically it's possible if you record the group/attrs in With/WithGroup
yourself and only call the wrapped handler in Handle, but you lose any
preformatting performance benefits a handler may have implemented.)

- sean


On Mon, Oct 23, 2023 at 2:50 PM Johann Höchtl 
wrote:

> As I got zero reply to that answer, let me rephrase it probably more
> easily:
>
> I would like to use slog, no other logging library
> I would like to have an entry called eventID which is at the root level
> and has a unique uuid for every log entry
> I would like to use a group for every application specific key-val pairs
>
> What I trired so far:
>
>- Use a Handler to add eventID : The key gets added to the logger yet
>at the group nesting level, not at the root level
>- Use a ReplaceAttr-Function: I add the key on initiailisation yet
>leave the value unassigned to Replace it in the ReplaceAttr-Function: The
>ReplaceAttr-Function sees the  root level addded eventID only untill a call
>to .WithGroup, then the  eventId is no longer available within the
>ReplaceAttr-Function
>
>
> Any help?
> Johann Höchtl schrieb am Donnerstag, 5. Oktober 2023 um 17:59:30 UTC+2:
>
>> I created a custom slog Handler which adds an attribute eventId which is
>> a GUID
>>
>> A NewLogger function returns that logger wrapped into a group: Every
>> further key-value provided should go into that group.
>>
>> Unfortunately the eventId also gets promoted into that group although it
>> should be at the parent level.
>>
>> See here the Goplay https://play.golang.com/p/a10f09jMwL3
>>
>> Thank you for your help, Johann
>>
> --
> 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/16dc9f51-6c8c-4fd9-9942-5e365399e26dn%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/CAGabyPokE8SKBtqKiUNs9_aieX2mWdxKm4XrwOoYOoe6jV%3DMUA%40mail.gmail.com.

Re: [go-nuts] Re: Weird error when trying to fetch a module.

['Sean Liao' via golang-nuts]

Modules in subdirectories should just work, tags are not necessary.
I see there is a recent commit to correct the module name, that was
necessary.

As for your most recent invocation, the module path was wrong (missing a
/src/ component)

$ go get
github.com/flatgeobuf/flatgeobuf/src/go@v0.0.0-20230914202020-25c11d75fe28
go: downloading github.com/flatgeobuf/flatgeobuf
v0.0.0-20230914202020-25c11d75fe28
go: downloading github.com/flatgeobuf/flatgeobuf/src/go
v0.0.0-20230914202020-25c11d75fe28
go: added github.com/flatgeobuf/flatgeobuf/src/go
v0.0.0-20230914202020-25c11d75fe28
go: added github.com/google/flatbuffers v22.11.23+incompatible

- sean


On Fri, Sep 15, 2023 at 4:35 PM Bruno Albuquerque  wrote:

> So, I am still curious about something. Flatbuffers, which is a project I
> depend on, does have its go code in a subdirectory and I can go get it:
>
> ➜  ~ go get -x github.com/google/flatbuffers/go
> # get https://proxy.golang.org/github.com/@v/list
> # get https://proxy.golang.org/github.com/google/flatbuffers/@v/list
> # get https://proxy.golang.org/github.com/google/flatbuffers/go/@v/list
> # get https://proxy.golang.org/github.com/google/@v/list
> # get https://proxy.golang.org/github.com/@v/list: 404 Not Found (0.156s)
> # get https://proxy.golang.org/github.com/google/@v/list: 404 Not Found
> (0.230s)
> # get https://proxy.golang.org/github.com/google/flatbuffers/go/@v/list:
> 200 OK (0.236s)
> # get https://proxy.golang.org/github.com/google/flatbuffers/@v/list: 200
> OK (0.236s)
> # get https://proxy.golang.org/github.com/google/flatbuffers/go/@latest
> # get https://proxy.golang.org/github.com/google/flatbuffers/go/@latest:
> 404 Not Found (0.023s)
> go: added github.com/google/flatbuffers v23.5.26+incompatible
>
> As comparison, here is what I get for flatgeobuf:
>
> ➜  ~ go get -x github.com/flatgeobuf/flatgeobuf/go
> # get https://proxy.golang.org/github.com/@v/list
> # get https://proxy.golang.org/github.com/flatgeobuf/@v/list
> # get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/@v/list
> # get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/go/@v/list
> # get https://proxy.golang.org/github.com/@v/list: 404 Not Found (0.124s)
> # get https://proxy.golang.org/github.com/flatgeobuf/@v/list: 404 Not
> Found (0.126s)
> # get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/@v/list:
> 200 OK (0.130s)
> # get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/@latest
> # get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/@latest:
> 200 OK (0.023s)
> # get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/go/@v/list:
> 404 Not Found (4.152s)
> go: module github.com/flatgeobuf/flatgeobuf@upgrade found
> (v0.0.0-20230914202020-25c11d75fe28), but does not contain package
> github.com/flatgeobuf/flatgeobuf/go
>
> Is the difference simply that flatbuffers has an associated tag and
> flatgeobuf currently does not?
>
> While we are at it, I can not find the go.mod for flatbuffers! It is not
> in the root of the repository and also not inside the go subdir where the
> code resides. Is there some special casing for this project in place?
>
> -Bruno
>
> On Thu, Sep 14, 2023 at 5:58 PM Bruno Albuquerque  wrote:
>
>> It is likely that I am doing something stupid but as I am out of ideas,
>> here goes nothing.
>>
>> I pushed an initial Go flatgeobuf implementation here:
>>
>> github.com/flatgeobuf/flatgeobuf/src/go
>>
>> This directory in the repository has a go.mod file with the following
>> contents:
>>
>> module github.com/flatgeobuf/flatgeobuf/src/go
>> go 1.20
>> require github.com/google/flatbuffers v22.11.23+incompatible
>>
>> Just in case it might be relevant, the actual repository is
>> github.com/flatgeobuf/flatgeobuf, src/go is a subdirectory there.
>>
>> If I try to use this module, it fails. For example:
>>
>> # go get -u github.com/flatgeobuf/flatgeobuf/src/go
>> go: downloading github.com/flatgeobuf/flatgeobuf
>> v0.0.0-20230914202020-25c11d75fe28
>> go: module github.com/flatgeobuf/flatgeobuf@upgrade found
>> (v0.0.0-20230914202020-25c11d75fe28), but does not contain package
>> github.com/flatgeobuf/flatgeobuf/src/go
>>
>> What am I missing?
>>
>> -Bruno
>>
>> --
> 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/CAEd86TwVCmcVBfKasTKYv804oJeJJ_dEoQ1SVPaJ2_nEhO0RUw%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 

Re: [go-nuts] Re: [slog] customize defaultHandler

['Sean Liao' via golang-nuts]

cycle:
https://go.dev//issues/61892

default handler, copied/exported:
https://pkg.go.dev/github.com/jba/slog/handlers/loghandler

- sean


On Tue, Aug 29, 2023 at 7:53 AM Marcello H  wrote:

> Yesterday, I came up with the same question and found this:
> "github.com/lmittmann/tint"
>
> (This solution still uses os.Stdout, but I think this can do what you
> need.)
>
> An example:
> logOptions := {
> NoColor: true,
> Level: slog.LevelError,
> TimeFormat: time.DateTime,
> }
> logHandler := tint.NewHandler(os.Stdout, logOptions)
> logger := slog.New(logHandler)
> slog.SetDefault(logger)
> slog.Info("this does not show")
> slog.Debug("this debug info does not show")
> logOptions.Level = slog.LevelInfo
> slog.Info("this is now visible")
> slog.Debug("this debug info still does not show")
> logOptions.Level = slog.LevelDebug
> slog.Info("this is still visible")
> slog.Debug("this debug info also shows")
> Op dinsdag 29 augustus 2023 om 03:00:01 UTC+2 schreef Mike Schinkel:
>
>> Hi Tamás,
>>
>> Have you actually tried that and gotten it to work? It does not compile
>> for me but this does (note method call vs. property reference):
>>
>> slog.SetDefault(slog.New(myHandler{Handler:slog.Default().Handler()}))
>>
>> However, when delegating the Handle() method it seems to cause an infinite
>> loop:
>>
>> func (m MyHandler) Handle(ctx context.Context, r slog.Record) error {
>> return m.Handler.Handle(ctx, r)
>> }
>>
>> See https://goplay.tools/snippet/qw07m0YflLd
>>
>> I know about this because just this past weekend I was trying to write a
>> TeeHandler to output the default to the screen and JSON to a file just
>> this
>> past weekend and ran into an infinite loop problem with the default
>> handler.
>>
>> I tried my best to figure out why it needed to be structured the way it
>> was
>> in that it seems to call itself recursively. I wanted to post a question
>> to
>> this list to see if there was a workaround, or if not to see if there
>> might
>> be interest in allowing it to work, but I could not get my head around it
>> so
>> eventually gave up and just used the TextHandler instead.
>>
>> Shame though. It would be nice to be able to reuse the default handler but
>> AFACT it is not possible (though if I am wrong I would love for someone to
>> show me how to get it to work.)
>>
>> -Mike
>>
>>
>> On Monday, August 28, 2023 at 12:50:50 PM UTC-4 Tamás Gulácsi wrote:
>>
>> slog.SetDefault(slog.New(myHandler{Handler:slog.Default().Handler}))
>>
>> vl...@mailbox.org a következőt írta (2023. augusztus 28., hétfő,
>> 15:06:37 UTC+2):
>>
>> Hi,
>>
>> When reading trough the log/slog documentation, it seems one can create
>> a logger with a different handler, which is either NewTextHandler or
>> NewJSONHandler.
>>
>> Why can't I configure the defaultHandler? Let's say I want my logger to
>> behave exactly like the defaultHandler, but output to a logfile or
>> Stdout instead.
>>
>> The defaultHandler's output is different compared to the NewTextHandler:
>>
>> slog.Info("ok"), gives me:
>>
>> INFO ok
>>
>> The NextTextHandler gives me:
>>
>> level=INFO msg="ok"
>>
>>
>> Regards,
>>
>> --
> 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/df136f1e-0283-46fa-a0b7-ce17a0722fd9n%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/CAGabyPo9NZJBf%3Dj-W_8tUS%3DqkmwHRWVpjCbFz04jZW_P8KEOow%40mail.gmail.com.

Re: [go-nuts] How to be a good slog module?

['Sean Liao' via golang-nuts]

If your modules are mostly structs with lifecycle methods,
do it like http.Server where the logger is a field (or option passed into
the constructor).

Else if your modules take contexts, you could consider having your own
WithLogger / FromContext funcs to pass a logger in a context.
An  advantage of this over a (declined in slog) global context key
is that this allows your consumers to target your module with a specific
logger.

Finally, you can do the same as log / slog are doing with Default()
SetDefault()
possibly guarded with an RWMutex, or just document that it's unsafe to
change after start.

Personal preference is for 1,
and whether you take a Logger vs Handler
would just be if you have a preference for a different frontend.

- sean


On Wed, Aug 23, 2023 at 7:09 PM TheDiveO  wrote:

> Up front, I admit my sin of arrogance in giving structured logging the
> slip these past years and misusing logrus just as a text logger with
> multiple log levels. This question is kind of my atoning...
>
> For preparation, I've read through (today's?) Go slog blog post, as well
> as some comparably recent 3rd party blog posts about Golangs new slog.
>
> What I haven't found (or maybe stubbornly refused to see) is: as I want to
> convert my existing consumable modules to slog, how am I going to be a good
> citizen, so other modules can easily consume my modules with proper control
> over logging? How am I giving my module "customers" control over per-module
> (but not necessarily per-package) logging? Are there already best practises
> and what are they?
>
> While ponding these questions, I would suspect, that creating a per-module
> default "slogger" when none has been set in a module's init() would be a
> bad idea: due to the order of module initialization, all my module
> customers/consumers would end up with the default slogger that mostly would
> not fit their needs.
>
> Simply exposing a public variable would be either suffering the init
> problem, or alternatively, I would create default sloggers that then have
> to be garbage collected anyway.
>
> And now, Ladies and Gentlemens, show me your consumable slogging please! I
> want to learn!
>
> --
> 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/cc4f2bcb-4972-4966-b2ff-341f29339d67n%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/CAGabyPp%3DFh5ff7bf0VWr-KttLxreMHEU_0-yqdVjCJKB8UjTwQ%40mail.gmail.com.

Re: [go-nuts] Re: Using underscore in return statements - a small convenience idea

['Sean Liao' via golang-nuts]

see also:

https://go.dev/issues/19642
https://go.dev//issues/21182

- sean


On Wed, Aug 23, 2023 at 3:10 PM Nick Craig-Wood  wrote:

> Ah ha! I thought there would be a related issue I couldn't find :-)
>
> `zero` would remove most of the pain though IMHO `_` looks neater in the
> return statements!
>
> Thanks for the pointer Brian.
>
> --
> 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/9393cf35-0831-4c5d-a0c8-da639e7443a2n%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/CAGabyPo9QgbXzTRPW2px6iwmiquhhL3ZhSxPGjkA4KtVDD%2B2Rw%40mail.gmail.com.

Re: [go-nuts] possible bug in slogtest or ReplaceAttr

['Sean Liao' via golang-nuts]

please file it as a bug for jsonhandler

- sean

On Fri, Aug 18, 2023, 21:17 jal...@gmail.com  wrote:

> Hi all,
>
> In slog, I am experimenting with the the ReplaceAttr func in the
> HandlerOptions with json handler. My understanding is that if i want to
> remove an attribute then return an empty slog.Attr. However, logtest test
> fails with a json unmarshal error. Note I am literally using the code
> example from the official docs.
>
> Is this expected or a  bug? Not sure what my user error is here.
>
> https://go.dev/play/p/i7VtMtNK4eV
>
> Thanks,
> Joe
>
> --
> 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/89810de6-6a02-440f-988b-9503845a8c90n%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/CAGabyPpww3p8%2BpU%3DWM4QTOYmOE2eqd-VCh4Rpnvq9aHyfnKxVw%40mail.gmail.com.

Re: [go-nuts] Is go test the wrong tool to use for a pure test harness?

['Sean Liao' via golang-nuts]

you can compile a test binary with `go test -c` and execute it later

- sean

On Sun, Aug 13, 2023, 18:28 dave bronte  wrote:

> Forgive me for what might at first glance look like a provocative subject
> line - it's not meant to be.
>
> The team that I work in has been asked to develop a system that will test
> a web service. We won't have access to the source for the web service so
> we're going to need to test it in its deployed state.
>
> For a number of reasons, Go would probably be a first choice for the team
> but
> it's my understanding that if we use "go test" then the code will only get
> built as a precursor to running the tests.
>
> As I currently see it, this would mean we couldn't have the benefit of a
> CI build without also  incurring the penalty of running a (potentially very
> slow) set of tests.
>
> Note that I'm not suggesting that we don't automate the running of the
> tests too, just that we'd like to decouple that from the check-in/build
> process.
>
> I may be missing something glaringly obvious to others but are Go and Go
> Test just the wrong tools for this problem?
>
> --
> 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/67481799-1f2c-47af-b242-446fe32d651bn%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/CAGabyPpMiAKmWJ5K8rUqtHrOm17Gvzyh_8OR8R1OC0_zT2b-zw%40mail.gmail.com.

Re: [go-nuts] How to minimize RAM usage during Go binary compilation

['Sean Liao' via golang-nuts]

considering it is primarily static information, maybe it should be passed
in and as data during run time, instead of being embedded and compiled as
code?

- sean

On Wed, Jul 12, 2023, 13:18 Jason Kulatunga  wrote:

> Hi,
>
> I’m doing something a bit unusual with my application and I’m trying to
> figure out if there’s a better way to do this that I’m missing.
>
> Basically my application Fasten Health
>  is designed to allow
> patients to pull their medical records from healthcare institutions — of
> with there are 10,000 currently supported, and 100,000s more that we'd like
> to support in the US.
>
> We have a repo/library called fasten-sources
>  which is made up of
> mostly generated code (using dave/jennifer
> ).
> It has a couple of primary packages:
>
>
>- pkg
>
> 
>which contains a list 10,000 enums, one for each support healthcare
>institution.
>- definitions/internal/source
>
> 
>which contains a public function defining the OAuth configuration for each
>healthcare institution
>- clients/internal/source
>
> 
>which contains a public function effectively instantiating a custom
>API/Http client for each healthcare institution
>
>
> All external references to this library use a Factory pattern -
> https://github.com/fastenhealth/fasten-sources/blob/main/clients/factory/factory.go
> — so the public functions do not need to be public in reality.
>
>
> At this point the build of our application (which leverages this library)
> is causing OOM issues during our Docker image build
> 
> on Github Actions and custom Depot.dev build nodes (64GB of memory)
>
> Here’s what I’m wondering:
>
>
>1. Could this OOM issue be caused by the number of public symbols in
>the packages? As we start supporting more and more institutions, I’d expect
>this number to grow by orders of magnitude, which will definitely cause
>even more OOM issues
>   - My functions/structs all match an interface, so if I change my
>   public functions to private functions, would that solve the problem in a
>   permanent way?
>2. Is the OOM issue caused by the number of files in a package?
>Instead of having 100,000s of individual files, if I had 1 massive file,
>would have have any impact?
>3. Is the OOM issue caused by the number of symbols in a single
>package? Should I find a way to distribute the enums, functions across
>multiple packages would have have any impact?
>4. Does the `internal` path have any impact on RAM usage during
>compilation?
>5. Instead of using a switch in the Factory for instantiating the
>clients and definition files, is there some other compiler friendly way to
>do this instead?
>
>
> Basically I recognize that I'm doing something a bit unusual, but I cant
> find a way around it. I need to support 100,000's of institutions in the
> future, so bandaid fixes (or "just use a bigger build machine") won't work
> for us. A fundamental refactor of the repo is completely acceptable, since
> its all generated code. I just don't know which changes will actually
> impact the amount of RAM used during compilation
>
> Thanks!
> -Jason
>
> --
> 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/f870ec97-5ac5-4211-9379-5f2c0dd97e0bn%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/CAGabyPrM_G6yzh19mLHCcKAkY4cSUMPAzXhCkQdSNZ35aEdUJg%40mail.gmail.com.

Re: [go-nuts] comment.Printer.DocLinkURL isn't being called

['Sean Liao' via golang-nuts]

your parsing setup is missing the lookup to identify which things are
actually linkable symbols

https://go.dev/play/p/sDtGA_JJZdz

- sean

On Sun, Jul 9, 2023, 23:45 will@gmail.com  wrote:

> I'm trying to print the Markdown for package documentation using the new
> go/doc/comment package. It seems like I have everything set up correctly to
> customize the doc link URLs, but the comment.Printer.DocLinkURL callback
> isn't being called:
>
> https://go.dev/play/p/7irKc6dTRRw
>
> The comment.Printer.HeadingID and HeadingLevel settings are working just
> fine.
>
> Am I missing something?
>
> --
> 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/41ce3de2-84a4-47a3-856d-0bc4543115fbn%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/CAGabyPpT6aJ4ozQ3E7GhBgBWyG4i0E_qtUXj1HHEX7t5d5FQgQ%40mail.gmail.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

['Sean Liao' via golang-nuts]

It is not a typo

https://go.dev/issue/24451

- sean


On Sat, Jun 3, 2023 at 10:05 PM peterGo  wrote:

> It's a simple typo. Send in a fix.
>
> peter
>
> On Saturday, June 3, 2023 at 4:07:15 PM UTC-4 Kamil Ziemian wrote:
>
>> As burak serdar said, 9 = 3 * 3 is not a prime number, all other elements
>> in the slice are prime numbers. It looks like authors of Go Spec want to
>> make a joke or check how well people read examples in it.
>>
>> Best regards,
>> Kamil
>> sobota, 3 czerwca 2023 o 21:52:37 UTC+2 burak serdar napisał(a):
>>
>>> On Sat, Jun 3, 2023 at 1:40 PM peterGo  wrote:
>>>

 Kamil Ziemian,

 // list of prime numbers
 primes := []int{2, 3, 5, 7, 9, 2147483647 <(214)%20748-3647>}

 The variable prime is a list of some prime numbers starting with the
 lowest and ending with the highest prime numbers that can safely be
 represented an int. An int may either 32 or 64 bits.

 Please explain the joke.

>>>
>>> Could it be that 9 is not prime?
>>>
>>>


 Note: “Explaining a joke is like dissecting a frog. You understand it
 better but the frog dies in the process.”
 ― E.B. White

 peter
 On Saturday, June 3, 2023 at 3:13:28 PM UTC-4 Kamil Ziemian wrote:

> Is this example found in the "Composite literals" section of Go Spec
> a joke?
> // list of prime numbers
> primes := []int{2, 3, 5, 7, 9, 2147483647 <(214)%20748-3647>}
>
> I checked on the internet and 2147483647 <(214)%20748-3647> is a
> prime number (https://en.wikipedia.org/wiki/2,147,483,647), so this
> element is fine.
>
> Best regards
> Kamil
>
> czwartek, 4 maja 2023 o 16:38:50 UTC+2 Kamil Ziemian napisał(a):
>
>> You convince me to your point Axel Wagner. At the same time if we
>> look at examples in Go Spec, I think their can be improved.
>> "A0, A1, and []string
>> A2 and struct{ a, b int }
>> A3 and int A4, func(int, float64) *[]string, and A5
>>
>> B0 and C0
>> D0[int, string] and E0
>> []int and []int
>> struct{ a, b *B5 } and struct{ a, b *B5 }
>> func(x int, y float64) *[]string, func(int, float64) (result
>> *[]string), and A5"
>> I mean, first we need to check that A0, A1 and []string are the same
>> type and after few examples like D0[int, string] is the same as E0, we 
>> have
>> stated []int and []int are the same type. If you convince yourself that 
>> A0
>> is the same as A1 and both are the same as []string, checking that []int
>> has the same type as []int is quite trivial. I would prefer that examples
>> would start from basic cases like []int is []int and []A3 is []int (if 
>> this
>> one is true) and progress to more convoluted like D0[int, string] is E0.
>>
>> Best regards,
>> Kamil
>>
>> czwartek, 4 maja 2023 o 14:12:25 UTC+2 Axel Wagner napisał(a):
>>
>>> Personally, I'd rather add more examples of "self-evidently equal
>>> types". In my opinion, all the type aliases in that block confuse 
>>> matters
>>> quite a bit.
>>>
>>> "[]int and []int are identical" is not actually self-evident at all.
>>> It is self-evident that any sensible definition of type identity 
>>> *should*
>>> make them identical. But it's not self-evident that the given definition
>>> *does*. Spelling that out in the example, means you are nudged to look 
>>> at
>>> the definition and see how their identity follows (by finding "Two slice
>>> types are identical if they have identical element types").
>>>
>>> In fact, whenever you define an equivalence relation, proving that
>>> it is reflexive is the very first step. And it's not always trivial. For
>>> example, `==` on `float64` is *not* reflexive. It seems obvious that 
>>> NaN ==
>>> NaN *should* hold from how it's spelled - but it doesn't.
>>>
>>> So, I disagree that the examples should limit themselves to cases
>>> where it's non-obvious that the two types should be identical.
>>>
>>> On Thu, May 4, 2023 at 12:35 PM Kamil Ziemian 
>>> wrote:
>>>
 There is a second such example just below "[]int and []int", but to
 understand it we need some more type declarations, I listed them below.
 `type (
 A0 = []string
 A1 = A0
 A2 = struct{ a, b int }
 A3 = int
 A4 = func(A3, float64) *A0
 A5 = func(x int, _ float64) *[]string

 B0 A0
 B1 []string
 B2 struct{ a, b int }
 B3 struct{ a, c int }
 B4 func(int, float64) *B0
 B5 func(x int, y float64) *A1

 // Unimportant part.
 )`
 The line in question is
 "struct{ a, b *B5 } and struct{ a, b *B5 }"
 which is true, but again feel out of place. I only start grasping
 rules of types identity, but I make guess that it should be 

Re: [go-nuts] Importing a package declared in the root directory of a module

['Sean Liao' via golang-nuts]

the import path specifies the location to find a package, but the actual
identifier used is the one in the package declaration, so

import "a_module_path"

var foo = util.Foo

- sean

On Sat, Apr 15, 2023, 20:40 Victor Giordano  wrote:

> Thanks *Sean!!*
> That makes sense for me!
>
> But i guess I must import with an alias as import without an alias
> doesn't works, right?
>
> @:/cmd$ go build .
> # a_module_path/cmd
> ./main.go:4:2: imported and not used: "a_module_path" as util
> ./main.go:9:14: undefined: a_module_path
>
> main.go
> package main
>
> import (
> "a_module_path"
> "fmt"
> )
>
> func main() {
> fmt.Println(a_module_path.Abs(-2))
> }
>
> I mean... i'm actually importing it without utill.. so the message kind of
> confuse me.
>
> Thanks again.
> El sábado, 15 de abril de 2023 a las 16:34:01 UTC-3, Sean Liao escribió:
>
>> import "a_module_path"
>>
>> optionally rename it to make it clearer
>>
>> import util "a_module_path"
>>
>> - sean
>>
>> On Sat, Apr 15, 2023, 20:31 Victor Giordano  wrote:
>>
>>> Hi there!
>>>
>>> I was playing a little bit with modules and packages, regarding making
>>> projects.
>>> And I'm struggling to use a package (non-main) declared in the root
>>> directory.. allow me to show an example:
>>>
>>> This scenario,  I have project somewhere on my file system
>>> .
>>> ├── cmd
>>> │   └── main.go
>>> ├── go.mod
>>> └── util.go
>>>
>>> *go.mod*
>>> module a_module_path
>>>
>>> go 1.19
>>>
>>>
>>> *util.go*
>>> package util
>>>
>>> func Abs(x int) int {
>>> if x < 0 {
>>> return -x
>>> } else {
>>> return x
>>> }
>>> }
>>>
>>> And the problem appears when I try to use the package util (in the root
>>> directory of the module) within another package of the module...
>>>
>>> *cmd/main.go*
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "a_module_path/util" // this doesn't works
>>> "a_module_path/../util" // this attemp neither (and as relative import
>>> paths are not supported in module mode i guess is a no-go)
>>> )
>>>
>>> func main() {
>>> fmt.Println(util.Abs(-2))
>>> }
>>>
>>> The question, as you may predict, is *¿If there any way to make this
>>> work?*
>>> *I do not want to create a folder named util (or whatever) and place
>>> there the util package.*
>>>
>>> Thanks for the reading and the patience!
>>> Keep rocking code!
>>>
>>> --
>>> 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/05b29995-e451-4235-a613-8193d995efcdn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/05b29995-e451-4235-a613-8193d995efcdn%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/f5bd0bd6-dc15-4160-89a0-34ae4d89d70bn%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/f5bd0bd6-dc15-4160-89a0-34ae4d89d70bn%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/CAGabyPqs%2BHUse780M-CdYaAYR%3D8qSdWotYxE5QSqJZwfSD65SA%40mail.gmail.com.

Re: [go-nuts] Importing a package declared in the root directory of a module

['Sean Liao' via golang-nuts]

import "a_module_path"

optionally rename it to make it clearer

import util "a_module_path"

- sean

On Sat, Apr 15, 2023, 20:31 Victor Giordano  wrote:

> Hi there!
>
> I was playing a little bit with modules and packages, regarding making
> projects.
> And I'm struggling to use a package (non-main) declared in the root
> directory.. allow me to show an example:
>
> This scenario,  I have project somewhere on my file system
> .
> ├── cmd
> │   └── main.go
> ├── go.mod
> └── util.go
>
> *go.mod*
> module a_module_path
>
> go 1.19
>
>
> *util.go*
> package util
>
> func Abs(x int) int {
> if x < 0 {
> return -x
> } else {
> return x
> }
> }
>
> And the problem appears when I try to use the package util (in the root
> directory of the module) within another package of the module...
>
> *cmd/main.go*
> package main
>
> import (
> "fmt"
> "a_module_path/util" // this doesn't works
> "a_module_path/../util" // this attemp neither (and as relative import
> paths are not supported in module mode i guess is a no-go)
> )
>
> func main() {
> fmt.Println(util.Abs(-2))
> }
>
> The question, as you may predict, is *¿If there any way to make this
> work?*
> *I do not want to create a folder named util (or whatever) and place there
> the util package.*
>
> Thanks for the reading and the patience!
> Keep rocking code!
>
> --
> 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/05b29995-e451-4235-a613-8193d995efcdn%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/CAGabyPqDhNox%3DLCOSkbLZaVpQF74ubzroL%3DWOkDuYMdb0zvoVA%40mail.gmail.com.

Re: [go-nuts] Is there a golang download for latest patch release like 1.20.x?

['Sean Liao' via golang-nuts]

What page are you looking at?

https://go.dev/dl/

- sean


On Thu, Mar 30, 2023 at 6:17 PM silverwind  wrote:

> Is there a way to download the latest patch release of golang 1.20 which
> currently is at 1.20.2. On the available downloads, I only find explicit
> links:
>
> https://go.dev/dl/go1.20.linux-amd64.tar.gz is the initial 1.20 release
> https://go.dev/dl/go1.20.2.linux-amd64.tar.gz ist the latest patch release
>
> I would lika a link that resolves to the latest patch release for the 1.20
> release, like
>
> https://go.dev/dl/go1.20.latest.linux-amd64.tar.gz
>
> Does it exist?
>
> --
> 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/39143ad1-4af5-4f36-8af8-a0fc85404024n%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/CAGabyPq5Yg19NNYPNm6cTU8vPiaWHUfHz8ieOWT%3DFQWphybKFQ%40mail.gmail.com.

Re: [go-nuts] Redfining loop variable semantics - what's the plan?

['Sean Liao' via golang-nuts]

https://go.dev/issue/57969

- sean

On Sat, Mar 25, 2023, 06:45 Amnon  wrote:

> Hi Gophers,
> Last year there was a discussion about removing one of the
> more common gotchas in Go.
>
> To quote from the discussion:
>
> the problem is that loops like this one don’t do what they look like they
> do:
>
> var all []*Item
> for _, item := range items { all = append(all, ) }
>
> That is, this code has a bug. After this loop executes, all contains
> len(items) identical pointers, each pointing at the same Item, holding
> the last value iterated over. This happens because the item variable is
> per-loop, not per-iteration:  is the same on every iteration, and
> item is overwritten on each iteration.
> https://github.com/golang/go/discussions/56010
>
> What was the resolution of this discussion?
> Was the proposed change accepted?
> Will it be released in Go 1.21 or 1.22?
>
> It is hard to figure this out from the discussion. There are hundreds of
> comments,
> but there is no clear marking of the resolution (apart from the discussion
> now being closed) either at the top of bottom of the discussion.
>
>
> --
> 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/5d88208e-fbbf-44d5-b693-50deff176fedn%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/CAGabyPq0Ffzw2O1wmQ4Qd-uoFrzyUhUuhqSYA-Na1vSbkHo4nQ%40mail.gmail.com.

Re: [go-nuts] Minor Omission in List on https://pkg.go.dev/golang.org/x

['Sean Liao' via golang-nuts]

https://go.dev/issue/56482

- sean


On Sat, Mar 11, 2023 at 7:35 AM Ian Lance Taylor  wrote:

> On Fri, Mar 10, 2023 at 2:54 PM jlfo...@berkeley.edu
>  wrote:
> >
> > Shouldn't "term" be included in the list shown on
> https://pkg.go.dev/golang.org/x?
> >
> > Going directly to https://pkg.go.dev/golang.org/x/term appears to work
> fine.
>
> Probably.
>
> I believe that there is an explicit list in
> golang.org/x/website/_content/pkgroot.tmpl.
>
> 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/CAOyqgcU%3DD4k6Pch3wZ5fgk8mHcXJ6_Wdn%3DtgX134jaVvKQoJCg%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/CAGabyPrLseZ%3DYmnSt2hgF0ufCjmmejRuYygDTPO%3DHvLVhpCa%2BA%40mail.gmail.com.

Re: [go-nuts] "go test": common prefix for errors

['Sean Liao' via golang-nuts]

implementing a helper/wrapper on your side might be easier, I believe most
helpers take the TB interface rather than the concrete T type.
also it sounds more like a failure of the application to separate its
output streams properly.

-- 
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/CAGabyPrOQ1%2B4%2BLiGQx4G4wgy6Ki%2BtQyLkeH%2Bu3GrXD_YsPGyvQ%40mail.gmail.com.

Re: [go-nuts] Re: heap profiling does not work on M2 MacBook air?

['Sean Liao' via golang-nuts]

fwiw, that code works on my machine :tm:

1:40:47 ~/tmp/testrepo0120 0:00:27
main » go run .
1:40:58 ~/tmp/testrepo0120 0:00:08
main » go tool pprof mem.prof
File: testrepo0120
Type: inuse_space
Time: Mar 2, 2023 at 1:40am (CST)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top10
Showing nodes accounting for 513.31kB, 100% of 513.31kB total
  flat  flat%   sum%cum   cum%
  513.31kB   100%   100%   513.31kB   100%  regexp/syntax.(*compiler).inst
(inline)
 0 0%   100%   513.31kB   100%  regexp.Compile (inline)
 0 0%   100%   513.31kB   100%  regexp.MustCompile
 0 0%   100%   513.31kB   100%  regexp.compile
 0 0%   100%   513.31kB   100%
 regexp/syntax.(*compiler).compile
 0 0%   100%   513.31kB   100%  regexp/syntax.(*compiler).rune
 0 0%   100%   513.31kB   100%  regexp/syntax.Compile
 0 0%   100%   513.31kB   100%  runtime.doInit
 0 0%   100%   513.31kB   100%  runtime.main
 0 0%   100%   513.31kB   100%
seehuhn.de/go/pdf/font/tounicode.init

- sean


On Wed, Mar 1, 2023 at 11:25 PM Jochen Voss  wrote:

> The problem also occurs on AMD64 Linux, so it's not architecture
> specific.  Hints would be most welcome!
>
> On Wednesday, 1 March 2023 at 13:55:30 UTC Jochen Voss wrote:
>
>> Dear all,
>>
>> I'm trying to profile memory use of a program, following the instructions
>> at https://go.dev/blog/pprof , but I can't get memory profiling to
>> work.  Am I doing things wrong, or is this broken?
>>
>> Simplified code is at https://go.dev/play/p/Wq_OU49LVQZ .  (The code
>> doesn't run on the playground, but you can download it and run it locally.)
>>
>> Following the advice from https://pkg.go.dev/runtime/pprof I added the
>> following code to the end of my main() function:
>>
>> f, err := os.Create("mem.prof")
>> if err != nil {
>> log.Fatal("could not create memory profile: ", err)
>> }
>> runtime.GC() // get up-to-date statistics
>> if err := pprof.WriteHeapProfile(f); err != nil {
>> log.Fatal("could not write memory profile: ", err)
>> }
>> err = f.Close()
>> if err != nil {
>> log.Fatal(err)
>> }
>>
>> When I run the code, this gives me a "mem.prof" file (5084 bytes).  But
>> when I start "go tool pprof" on this file, I get
>>
>> >>> go tool pprof xxx mem.prof
>> File: xxx
>> Type: inuse_space
>> Time: Mar 1, 2023 at 1:15pm (GMT)
>> No samples were found with the default sample value type.
>> Try "sample_index" command to analyze different sample values.
>> Entering interactive mode (type "help" for commands, "o" for options)
>> (pprof) top10
>> Showing nodes accounting for 0, 0% of 0 total
>>   flat  flat%   sum%cum   cum%
>>
>> There seem to be no samples in this file.
>>
>> What am I doing wrong?
>>
>> All the best,
>> Jochen
>>
>> --
> 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/4e85c396-ef29-41d5-9bb6-5b950648287fn%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/CAGabyPpMNVc8-KpNaEAMm4X7eTy7H1r92acuAj7iHuU%2BXJLtWw%40mail.gmail.com.

Re: [go-nuts] Go 1.20 "cold start" slows down CI pipeline stages due to first building stdlib

['Sean Liao' via golang-nuts]

- restore cache (go version as cache key)
- go build std
- save cache (GOCACHE)
- original build steps follow here

- sean

On Thu, Feb 16, 2023, 19:54 TheDiveO  wrote:

> As Go 1.20 doesn't ship anymore with prebuild stlib packages, the first
> build after installation will take longer. Obviously, in a full Kubernetes
> build this is negligible (if not outward laughable). But for many small CI
> Go build stages this probably eats considerably into CPU time and energy
> consumption.
>
> For instance, a small module
> https://github.com/thediveo/caps/actions/runs/4197604787 takes around 36s
> for Go 1.19 versus Go 1.20 with 63s (times for "go test" phase only).
>
> Now I'm curious: is there some way to "preheat" Go 1.20 in order to cache
> the locally built Go stdlib?
>
> --
> 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/e300c706-da67-4cb9-8a37-bf15bd041e7dn%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/CAGabyPpYTiYa7oixaiJvFSWzrC96M-dwRRy6gP%3D8AK6CdcK9nA%40mail.gmail.com.

Re: [go-nuts] GOPATH, GOBIN, go install, go build, cross-compiles

['Sean Liao' via golang-nuts]

> GOCACHE seems to default to ~/.cache/go-build on my machine.
> Shouldn't GOMODCACHE do the same?

That was decided against:
https://go.dev/issue/34527#issuecomment-559185776

> ... It would be super interesting to
> have in-repo or in-module metadata that could be used for these flags.

General build configurations have been declined:
https://go.dev/issue/39005
https://go.dev/issue/42343

There may be appetite for a single set of per-project default config though:
https://go.dev/issue/57179#issuecomment-1345398917

Right now, GOENV=path/to/file for every config could work in combination
with GOFLAGS,
now that quoting is allowed after https://go.dev/issue/26849

- sean


On Fri, Jan 20, 2023 at 7:30 PM Tim Hockin  wrote:

> Thanks Sean.
>
> On Fri, Jan 20, 2023 at 10:39 AM 'Sean Liao' via golang-nuts
>  wrote:
> >
> > in module mode,
> > GOPATH is really only used for deriving default locations for GOBIN and
> GOMODCACHE
> > setting it to /dev/null might not be great for caching dependencies if
> GOMODCACHE isn't set
>
> I think it would bring some closure if we could definitively say
> "GOPATH isn't needed".
>
> GOCACHE seems to default to ~/.cache/go-build on my machine.
> Shouldn't GOMODCACHE do the same?
>
> > cross compile to GOBIN was recently (re)opened
> > https://go.dev/issue/57485
>
> Great - I voted it up, but I don't know if that helps at all.  Setting
> GOBIN would be a better solution for k8s, if it only worked.
>
> Another thing that we end up writing scripts for is the various sets
> of build flags.  Like, if you want to build debug binaries there are
> something like 4 flags to change.  It would be super interesting to
> have in-repo or in-module metadata that could be used for these flags.
>
> For example, what if I could add something that said "GOBIN=./bin" or
> even more flexible.
>
> > There are open requests to print out the directory where it would be
> installed,
> > (presumably to update PATH) but not for the actual binaries built.
> > https://go.dev/issue/45546
>
> Also voted up, but it seems stalled.
>
> > -o dir/ ending in a slash is documented as:
> > > If the named output is an existing directory or
> > > ends with a slash or backslash, then any resulting executables
> > > will be written to that directory.
>
> Sure, it's documented, but one mistake and all subsequent invocations
> fail.  It works, but it's just fragile.
>
> Tim
>
>
> > On Fri, Jan 20, 2023 at 5:30 PM 'Tim Hockin' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
> >>
> >> I'm trying to make kubernetes' codebase easier to navigate by people
> who have muscle-memory for go.  In the past we said "you have to call our
> Makefile" to build things.  I'd like to make \`go install\` work but I'm
> struggling to find a pattern that really works - am I missing something?
> >>
> >> First, GOPATH is dead.  I hate that Go silently writes to my home
> directory, which is ALMOST NEVER what I really wanted.
> >>
> >> Aside: is there any way to get `go install` and `go build` to tell me
> what they wrote?  Would that be a reasonable feature request?  E.g.
> >>
> >> ```
> >> $ go install --print-result 
> >> /home/thockin/go/bin/cmd
> >> ```
> >>
> >> I usually set GOPATH=/dev/null.
> >>
> >> ```
> >> $ GOPATH=/dev/null \
> >>   go install 
> >> go install : mkdir /dev/null: not a directory
> >> ```
> >>
> >> Good.  I want to install to a repo-local dir so all of our CI and stuff
> can find it.
> >>
> >> ```
> >> $ GOPATH=/dev/null \
> >>   GOBIN=./bin \
> >>   go install 
> >> ```
> >>
> >> That works.
> >>
> >> ```
> >> $ GOPATH=/dev/null \
> >>   GOBIN=./bin \
> >>   GOARCH=arm \
> >>   go install 
> >> go: cannot install cross-compiled binaries when GOBIN is set
> >> ```
> >>
> >> Well, shoot.  I can't find any other way for `go install` to work.
> >>
> >> ```
> >> $ GOPATH=/dev/null \
> >>   GOBIN=./bin \
> >>   GOARCH=arm \
> >>   go build 
> >> ```
> >>
> >> That works, but splats the file into the current dir.  To be fair, that
> is documented behavior.
> >>
> >> ```
> >> $ GOPATH=/dev/null \
> >>   GOARCH=arm \
> >>   go build -o ./bin 
> >> ```
> >>
> >> That works, except when ./bin doesn't exist, in which case it becomes
> the 

Re: [go-nuts] GOPATH, GOBIN, go install, go build, cross-compiles

['Sean Liao' via golang-nuts]

in module mode,
GOPATH is really only used for deriving default locations for GOBIN and
GOMODCACHE
setting it to /dev/null might not be great for caching dependencies if
GOMODCACHE isn't set

cross compile to GOBIN was recently (re)opened
https://go.dev/issue/57485

There are open requests to print out the directory where it would be
installed,
(presumably to update PATH) but not for the actual binaries built.
https://go.dev/issue/45546

-o dir/ ending in a slash is documented as:
> If the named output is an existing directory or
> ends with a slash or backslash, then any resulting executables
> will be written to that directory.

- sean


On Fri, Jan 20, 2023 at 5:30 PM 'Tim Hockin' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I'm trying to make kubernetes' codebase easier to navigate by people who
> have muscle-memory for go.  In the past we said "you have to call our
> Makefile" to build things.  I'd like to make \`go install\` work but I'm
> struggling to find a pattern that really works - am I missing something?
>
> First, GOPATH is dead.  I hate that Go silently writes to my home
> directory, which is ALMOST NEVER what I really wanted.
>
> Aside: is there any way to get `go install` and `go build` to tell me what
> they wrote?  Would that be a reasonable feature request?  E.g.
>
> ```
> $ go install --print-result 
> /home/thockin/go/bin/cmd
> ```
>
> I usually set GOPATH=/dev/null.
>
> ```
> $ GOPATH=/dev/null \
>   go install 
> go install : mkdir /dev/null: not a directory
> ```
>
> Good.  I want to install to a repo-local dir so all of our CI and stuff
> can find it.
>
> ```
> $ GOPATH=/dev/null \
>   GOBIN=./bin \
>   go install 
> ```
>
> That works.
>
> ```
> $ GOPATH=/dev/null \
>   GOBIN=./bin \
>   GOARCH=arm \
>   go install 
> go: cannot install cross-compiled binaries when GOBIN is set
> ```
>
> Well, shoot.  I can't find any other way for `go install` to work.
>
> ```
> $ GOPATH=/dev/null \
>   GOBIN=./bin \
>   GOARCH=arm \
>   go build 
> ```
>
> That works, but splats the file into the current dir.  To be fair, that is
> documented behavior.
>
> ```
> $ GOPATH=/dev/null \
>   GOARCH=arm \
>   go build -o ./bin 
> ```
>
> That works, except when ./bin doesn't exist, in which case it becomes the
> output file (if I am building 1 thing) or I get an error (if I am building
> multiple things):
>
> ```
> $ GOPATH=/dev/null \
>   GOARCH=arm \
>   go build -o ./bin  
> go: cannot write multiple packages to non-directory ./foo
> ```
>
> I can specify a directory by adding a trailing `/` it seems:
>
> ```
> $ GOPATH=/dev/null \
>   GOARCH=arm \
>   go build -o ./bin/  
> ```
>
> That seems to work, but I have to get the invocation JUST RIGHT 100% of
> the time or risk causing weird errors and CI fails.  The obvious answer is
> "wrap it in a script or Makefile", which puts me right back where I started.
>
> Is there a better answer?
>
> Tim
>
> --
> 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/d04fca5a-8b85-4386-9bae-50853f317fccn%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/CAGabyPocd8cx%3Dyg1arT74ULHoLjB4eNrUm17dqAw6KG8SazmPA%40mail.gmail.com.

Re: [go-nuts] Is OCSP Stapling supported in Go? If so, how?

['Sean Liao' via golang-nuts]

The standard library itself doesn't do it, but it does provide you with
hooks to do so.
Set crypto/tls.Config.GetCertificate to an appropriate implementation of
OCSP stapling.
Examples of ocsp stapling can be found via the package discovery site:
https://pkg.go.dev/search?q=ocsp+staple

- sean


On Mon, Dec 19, 2022 at 7:31 PM John Wayne  wrote:

> I tried to google this for a while now, and all I find regarding this
> topic is: https://groups.google.com/g/golang-nuts/c/QC5FOysyVxg
>
> This is already many years old, and to me it seems like there is code
> inside Go which allows to perform server side OCSP stapling. However, I am
> unable to find out *how* one would use this. Does this just work
> transparently in the background, all done by the Go library itself, or does
> the developer need to take measures when implementing an HTTP server using
> Go?
>
> I would test this out myself, but testing whether or not a given server
> provides the OCSP response in the handshake is not exactly trivial, since
> you would need to have a proper certificate with a working OCSP responder
> set up, which I don't.
>
> So I would really appreciate if someonce could shed a bit of light on this
> topic for me.
>
> 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/99634c56-6357-48b8-887f-9d27067182fan%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/CAGabyPou1ocoiKxAK0CPVDZ1C9UJnftqEhLnq61W_16gkm%2BbQg%40mail.gmail.com.

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

['Sean Liao' via golang-nuts]

https://go.dev/issue/26460

- sean


On Mon, Dec 19, 2022 at 7:31 PM David M  wrote:

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

-- 
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/CAGabyPobV%3DZZt2jV5yAjEkDffssnCZskrAFc1WG3%2BwvLV45tpw%40mail.gmail.com.

Re: [go-nuts] Refresher tutorial

['Sean Liao' via golang-nuts]

consider something like https://learnxinyminutes.com/docs/go/
if you just need a brief refresher on syntax/core concepts

- sean

On Sat, Dec 10, 2022, 17:17 Ken  wrote:

> Hi, when I first learned golang, there was a nice tutorial avaiable. I’m
> in need of a refresher as I haven’t used it in quite a while, but know
> there are 100’s of tutorials. Would like to find a recommended one where I
> could quickly brush up on functionality and syntax. Thanks! Ken
>
> Sent from my iPhone
>
> --
> 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/18BE6E52-574A-47D8-BFC7-CF9779F535DD%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/CAGabyPoea2yS0UW0EVQRHvXP8%2B7fNZq3nkM%3DoTSU5nisOkP3tQ%40mail.gmail.com.

Re: [go-nuts] HTTPS proxy issue using CONNECT method

['Sean Liao' via golang-nuts]

How are you setting the proxy?

- sean

On Sat, Dec 3, 2022, 16:46 Mauro Monteiro  wrote:

> Hello all,
>
> I have been facing an issue when I try to create a HTTP client which needs
> to connect through a HTTPS proxy using the HTTP CONNEC method. I know that
> it can be achieved setting my own http.Transport object. However the issue
> seems to be in the current implementation of /net/http/transport.go code.
>
> In my environment, I am developing a HTTP client which ALWAYS use a HTTPS
> proxy using HTTP CONNECT method. This client is allowed to reach HTTP or
> HTTPS targets. Therefore, I noticed that when I try to reach a HTTPS
> target, the the transport layer works as expected and it uses the HTTP
> CONNECT method. However, when I try to reach a HTTP target, the transport
> does not use the CONNECT  method.
>
> Looking at the transport.go code, I realized that the check to use the
> CONNECT method is based on the protocol of the target instead of being on
> the protocol of the proxy URL. Below is a link showing that:
>
> 1. HTTP check
>
>
> https://cs.opensource.google/go/go/+/refs/tags/go1.9.5:src/net/http/transport.go;l=1092
>
> 2. HTTPS check
>
>
> https://cs.opensource.google/go/go/+/refs/tags/go1.9.5:src/net/http/transport.go;l=1099
>
> As can be seen on the links above, the condition is based on cm
> 
> .targetScheme
> 
>  instead
> of cm
> 
> .proxyURL
> 
> .Scheme
> .
> Is it a bug?
>
> *Go version: go version go1.19.3 linux/amd64*
>
> Mauro
>
> --
> 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/d06cd78b-c012-425f-8b5e-52d4bd7a3cbcn%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/CAGabyPrBxj2m9kgNZrL5k3maGBu2Ljb%2B%3DONe2m-kr7Z8K3ArHA%40mail.gmail.com.

Re: [go-nuts] go install of forked repo

['Sean Liao' via golang-nuts]

`go install pkg@version` doesn't support installing from a fork.

The argument is best understood as a module identity rather than source
code location.

- sean

On Sat, Dec 3, 2022, 11:55 Duncan Harris  wrote:

> This seems a noddy question but can't easily find an answer with Google
> apparently. I may have lost the plot :-)
>
> There is a repo which contains source for a go executable that I want to
> use.
> Normally I install this with: go install original.domain/path@latest
> I want to fork that repo and make some experimental changes.
> So then I want to: go install my.forked.domain/path@commit
> But if I don't also change the go.mod file in my fork I get something like:
>
> go: downloading my.forked.domain/path v0.0.0-20221203102529-commit
> go: my.forked.domain/path@commit
> : my.forked.domain/path@v0.0.0-20221203102529-commit: parsing go.mod:
> module declares its path as: original.domain/path
> but was required as: my.forked.domain/path
>
> Obviously I could change the go.mod in my fork, but that seems wrong if I
> later want to submit a PR on the original repo.
>
> --
> 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/9a9542bd-1718-4ea7-a0ed-42b343bb9699n%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/CAGabyPoRcekTD0R7JB51%3DOSSVsyDLUsTEuGYjNvYUvOOGZuw7Q%40mail.gmail.com.

Re: [go-nuts] Re: gRPC for web applications with millions of users

['Sean Liao' via golang-nuts]

See also https://buf.build/blog/connect-web-protobuf-grpc-in-the-browser

- sean


On Fri, Dec 2, 2022 at 4:46 PM Brian Candler  wrote:

> Just checking that you came across this already?
> https://grpc.io/blog/state-of-grpc-web/
>
> gRPC can't be implemented natively in browsers. You can sending something
> gRPC-like and then convert it back to gRPC at the server.  But for
> bi-directional streaming, I think you need to look at Websockets or
> Server-Sent Events.
>
> On Friday, 2 December 2022 at 14:06:34 UTC Sankar wrote:
>
>> Hi,
>>
>> I have used gRPC for some simple applications, where the server is in
>> Golang and the client is also another golang application. I have primarily
>> worked in the backend and have done a lot of gRPC communication among the
>> backend services using the likes of gRPC streams and golang.
>>
>> Now for the first time, I am trying to implement a web application. The
>> client apps will be done in react-native. So I was thinking of using the
>> javascript gen code for the client libraries.
>>
>> However I read from some blogposts, when I searched for how to use gRPC
>> in javascript, I read that gRPC cannot be used for consumer facing
>> applications and is only fit for backend applications. I read that grpc
>> streaming will not work with Browser based applications.
>>
>> Also I read that gRPC will not scale if there are millions of user
>> requests coming from browsers. I am sure that gRPC can handle a lot of
>> backend volume, but I have not used with a lot of parallel connections.
>>
>> So I wanted to ask, if gRPC is used by any consumer facing applications,
>> where the backend  is done in Go and the front end is done in some form of
>> javascript framework, with a few million users.
>>
>> Any feedback, suggestions, links, etc. on this topic are also welcome.
>>
>> 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/15748f24-acfa-4061-8174-a03a894713c0n%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/CAGabyPpMUwvzgV3z9W1D7R8%3D%3DWS0jW1Vh0doJQ0Ed0LshhzUbA%40mail.gmail.com.

Re: [go-nuts] Fetch pseudo-versions

['Sean Liao' via golang-nuts]

all pseudoversions would be a list of all commits
are you sure that's what you want?

- sean

On Fri, Dec 2, 2022, 16:37 Marco Augusto Vitangeli <
marcoaugustovitang...@gmail.com> wrote:

> Hi, this question is a little bit weird, but for a project I need to list
> all versions of a golang package. Currently I'm doing it with the golang
> proxy, and the list endpoint, but it has one issue, it does not return
> pseudo versions. Do you have any idea o how can I access this information?
> some registry that I can fetch it or something. Thank you in advance.
>
> --
> 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/efe227f2-7fd3-49c6-bd7e-0a271e91bad6n%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/CAGabyPokRVwAh5QkF6GrbR1%3DjySGz4C56aW9W6vi4qdLbo5MmA%40mail.gmail.com.

Re: [go-nuts] where is GOROOT set?

['Sean Liao' via golang-nuts]

output of `go env` please

- sean


On Wed, Nov 23, 2022 at 11:25 PM pat2...@gmail.com 
wrote:

> I've separated my code into separate subdirectories, added a go.mod
> ran go mod tidy on each.
>
> I'm mostly back where I started, which a better source file tree
>
> I'm trying to test the "treesort" package from the "Donovan and Kernigan"
> The Go programing language book.
>
> When I connect into the treesort subdirectory, you can see the files, but
> I get a bad GOROOT error trying to do a "go test ."
>
> treesort$ ls
> go.mod  treesort.go  treesort_test.go
>
>
> pfarrell@Alien15:~/whome/sandbox/gows/treesort$ cat go.mod
> module github.com/pfarrell51/gows/treesort
>
> go 1.19
>
> pfarrell@Alien15:~/whome/sandbox/gows/treesort$ go test .
> # github.com/pfarrell51/gows/treesort
> treesort_test.go:11:2: package treesort is not in GOROOT (C:\Program
> Files\Go\src\treesort)
> FAILgithub.com/pfarrell51/gows/treesort [setup failed]
> FAIL
>
> How can I get past this?
> 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/4b365c67-6f3d-4edc-97d5-dbe505604818n%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/CAGabyPq5pSoL6w1Mbgj2A7ip7OuL2q1_hok7DBfcFK77fpxp-Q%40mail.gmail.com.

Re: [go-nuts] Re: is this a bug in "go fmt"?

['Sean Liao' via golang-nuts]

You'll need to provide more info if you want to report a bug:

```
main » cat main.go
// +build production
// +build linux

package main

21:13:35 ~/tmp/testrepo0017 0:00:00
main » go fmt .
main.go

21:13:39 ~/tmp/testrepo0017 0:00:00
main » cat main.go
//go:build production && linux
// +build production,linux

package main
```
- sean


On Fri, Nov 11, 2022 at 9:13 PM Sandeep Kalra 
wrote:

> and similar issue with other style of adding tags as well
>
> i.e.
> // +build tag1,tag2
> // +build tag1 tag2
> etc
>
> On Friday, November 11, 2022 at 3:07:40 PM UTC-6 Sandeep Kalra wrote:
>
>> Original code:
>>
>> $ cat production.go
>>
>> //go:build production
>> // +build production
>> // +build linux  << Notice This Line as my production code is only
>> available on Linux
>>
>> package main
>>
>> const (
>> isProductionCode = true
>> isDebugCode  = false
>> )
>>
>> $ go fmt production.go
>> production.go
>> $ cat production.go
>> //go:build production
>> // +build production
>>
>> package main
>>
>> const (
>> isProductionCode = true
>> isDebugCode  = false
>> )
>> Thanks,
>> Sandeep Kalra
>>
> --
> 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/9a4b4e5d-4c3f-469d-8cc5-6a268152cd5an%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/CAGabyPo71tHJcW3u%3DOrpmsaED4%2BZAfr9a80xz9DWSQSyK5C1%2Bg%40mail.gmail.com.

Re: [go-nuts] [ANN] Tool for automatic instrumentation of OpenTelemetry

['Sean Liao' via golang-nuts]

Interesting

As a note, directive comments should be of the form `//toolname:directive`,
meaning the `//go:` prefix should be reserved for the `go` toolchain itself.

- sean


On Thu, Nov 10, 2022 at 4:07 PM Nikolay Dubina 
wrote:

> *What?*
>
> Tool for automatic instrumentation of OpenTelemetry Traces of all
> functions and methods.
>
> https://github.com/nikolaydubina/go-instrument
>
> *Why?*
>
> It is laborious to add tracing code to every function manually. The code
> repeats 99% of time. Other languages can either modify code or have wrapper
> notations that makes even manual tracing much less laborious. As of
> 2022-11-06, official Go does not support automatic function traces.
> https://go.dev/doc/diagnostics. Thus, created a tool to automatically add
> Spans.
>
> *Thank you!*
>
> -- Nikolay
>
> --
> 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/0323b8d0-c1cc-47e9-9b32-82fecb4d9f66n%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/CAGabyPrkjpGU4YmrCY4Aw%2B1DMYscM6Hx-P8Byv-N4zMDV%3Dw9YA%40mail.gmail.com.

Re: [go-nuts] Re: behavior of %f

['Sean Liao' via golang-nuts]

> leaving one with the impression those digits will be as they are in the
float, and not rounded.

This is a fundamental misunderstanding of what a float is. The rounding
happens the moment a value is stored in a float. The printed value is
exactly what is stored.

- sean

-- 
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/CAGabyPoZdWMjYUiq_LS44tvyCzxmUYRbQs4%2BY_8s0uSmO_%2BdNw%40mail.gmail.com.

Re: [go-nuts] Internationalized webpage depending on the user's web browser locale

['Sean Liao' via golang-nuts]

.Lang comes from something gitea provided to the template, it's not an
intrinsic part of go

- sean

On Mon, Oct 10, 2022, 19:48 Christoph  wrote:

> Hello,
>
> I am running a git-server, powered by gitea, an open-source git server
> project written in Go. In gitea, it is possible to customize the home page,
> what I did. My customized home page, among other things, contains:
>
> {{if eq .Lang "de-DE"}}
>   Willkommen auf dem Git-Server der Fakultät für Informatik der TU
> Dortmund
>  {{else}}
>Welcome to the GIT server of the Faculty of Computer Science of
> the TU Dortmund
>  {{end}}
>
> This worked with gitea 1.14.5, compiled with some older version of golang,
> but unfortunately, it does not work in gitea 1.17.2, compiled with golang
> 1.19.1; the language of the displayed webpage is English, though my browser
> locale is German.
>
> As far as I found on the internet, the if-else-clause and the .LANG
> variable come from Go, so I ask here if anyone has an idea of how to make
> the above work again.
>
> Regards
>   Christoph
>
>
>
>
> --
> 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/ace1198c-d4c4-4208-9bc8-c5db0ae0cb48n%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/CAGabyPq1uCpi69N%2BhXK_bN578n4qN4ke1SFMU_AHpgPm4mEzmA%40mail.gmail.com.

Re: [go-nuts] Error-checking with errors.As() is brittle with regards to plain vs pointer types

['Sean Liao' via golang-nuts]

The documented api includes

> An error matches target if the error's concrete value is assignable to
the value pointed to by target

*T is not assignable to T

- sean

On Wed, Sep 21, 2022, 20:26 cpu...@gmail.com  wrote:

> Consider https://go.dev/play/p/jgPMwLRRsqe:
>
> errors.As(err, ) will not match if error is of pointer type.
> As a result, a library consumer needs to understand if a library returns
> Error or *Error. However, that is not part of the API spec as both returns
> would satisfy error if Error() is implemented on the plain type.
>
> A potential workaround would be using Error.As(any) to match plain/pointer
> type as part of the library. However, it seems counterintuitive having to
> do so if errors.As() doesn't by default.
>
> Would it make sense (and I would like to propose) to expand errors.As() to
> match plain receiver types even when err is a pointer to the same
> underlying plain type.
>
> What do you think?
>
> Cheers,
> Andi
>
> --
> 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/9c5fe0fb-de0c-4c09-b884-2f8153348fb7n%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/CAGabyPo%3DK%2B7EcTgRQN%3DDNjUUWNv5cBj5xS_Gw53kCuppvyL0gQ%40mail.gmail.com.

Re: [go-nuts] Detachable context.Context?

['Sean Liao' via golang-nuts]

https://go.dev/issue/40221

- sean

On Sat, Sep 3, 2022, 16:56 Alex Besogonov  wrote:

> Hi!
>
> Let me give you some context. context.Context in Go serves two main
> purposes:
> 1. Cancellation and timeout support.
> 2. A carrier of values, as a de-facto replacement for thread-local
> variables.
>
> I have a problem with the first item. Cancellation and timeouts
> automatically propagate to child contexts, which is usually a good thing.
> However, sometimes it would be nice to be able to create child contexts
> that share only values but not the timeout/cancellation.
>
> Typically it's needed if the code wants to start a background goroutine to
> do some work. E.g. in pseudocode:
>
> func StartConnection(ctx context.Context, addr string) (err error) {
>   conn, err = net.DialWithContext(ctx, addr)
>   if err != nil { return err; }
>   go heartbeatFunc(ctx, conn);
> ...
> }
>
> Right now it's not possible to do that cleanly. The only way is to create
> a brand new context and copy all the needed values. Which requires the code
> to know which values might be needed.
>
> Is there an interest in proposal to add this functionality? It can look
> like another method: `context.Detached(ctx context.Context)` that simply
> does not add it to the parent cancellation tree.
>
> --
> 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/26f54d88-e475-413e-84f0-9076f5aaba28n%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/CAGabyPpSEUDTucnfuYNQ68FpwnVFnMTWefL-z4_Kq-ABDtR_LA%40mail.gmail.com.

Re: [go-nuts] How to cross-compile Go 1.19 compiler for Solaris 11 on Linux

['Sean Liao' via golang-nuts]

That's a known issue, see:
https://go.dev/issue/53813
https://go.dev/issue/54197


- sean

On Wed, Aug 31, 2022, 21:35 Shane  wrote:

> I was finally able to compile the bootstrap on Linux (I had to install the
> missing libc).
>
> However, after copying the .tbz file onto my Solaris 11u4 AMD64 machine to
> build the final Go tools, building fails:
>
> $ GOROOT_BOOTSTRAP=/tmp/bootstap-goroot CGO_ENABLED=1 ./all.bash
> Building Go cmd/dist using /tmp/bootstap-goroot. (go1.19 solaris/amd64)
> dist: Cannot find /lib64/ld-linux-x86-64.so.2
>
> Why does the bootstrap go expect /lib64/ld-linux-x86-64.so.2? Shouldn't it
> only be looking for Solaris libs?
> On Saturday, August 27, 2022 at 3:18:42 PM UTC-4 Ian Lance Taylor wrote:
>
>> On Sat, Aug 27, 2022 at 12:15 PM Shane  wrote:
>> >
>> > My understanding then is that cmd/dist first builds for the host here
>> (in my case, for Linux) and then builds for the target starting here. Since
>> there is always a build for the host first, then since my host OS is Linux,
>> the linux_syscall.c is always part of the compilation (since I do not
>> disable cgo). If anything is incorrect with my understanding, please
>> correct me.
>> >
>> > I believe then I need to have both Linux system headers and Solaris
>> system headers available on my build machine for the cross-compile, if I
>> want to build Go for Solaris with cgo support.
>> >
>> > Is it possible for there to be two header files with the same name but
>> different OS have the same #include path in the cgo source code? If so,
>> could the C compiler get the correct header for the target of the cgo? For
>> example, how could the C compiler know to use the Linux unistd.h header for
>> the Linux build, and later use the Solaris unistd.h header for the Solaris
>> build?
>>
>> I'm not sure whether this answers your question, but normally a system
>> will have a native compiler that will look for header files in
>> /usr/include. It can also have a cross-compiler that looks for header
>> files in some other location. A cross-compiler should never look in
>> /usr/include, it should only look at the cross-compilation header
>> files.
>>
>> 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/6dd9a30f-d4be-45ff-a80c-499a71933259n%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/CAGabyPpx9AQ7Bsr56_zkt0pv3hsxJw9kqLe-4Pk_vSzj9kSCAQ%40mail.gmail.com.

Re: [go-nuts] How to cross-compile Go 1.19 compiler for Solaris 11 on Linux

['Sean Liao' via golang-nuts]

make.bash calls cmd/dist which does the build chaining, calling it directly
doesn't skip the process.

- sean

On Sat, Aug 27, 2022, 19:54 Shane  wrote:

> >  Is there some way I can skip straight to building Go for my Solaris
> target using my existing Linux Go tools?
> Sorry, this question was foolish. Of course I can skip straight to
> building for Solaris, by using the make.bash script.
>
> But as I pointed out earlier,
> > I looked at the POSIX docs
> ,
> and POSIX only has a setregid()
>  
> function,
> and not a setresgid()  function.
>
> And
> >  make.bash runs go build with the GOOS and GOARCH set to empty strings
> here 
> .
>
> Please correct me if I am wrong, but my assumption is that if GOOS was
> properly set to solaris by make.bash, then linux_syscall.c would not be
> compiled, and then I would not get the compiler error I am seeing.
>
> On Saturday, August 27, 2022 at 2:40:52 PM UTC-4 Shane wrote:
>
>> I already have a working Go 1.19 for Linux with cgo support on my build
>> machine that I downloaded and installed from https://go.dev. Given this,
>> is it still necessary to build for the host? Is there some way I can skip
>> straight to building Go for my Solaris target using my existing Linux Go
>> tools? Or if I do that, does that break the guarantee of a consistent final
>> artifact?
>
> --
> 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/ab7f958c-e662-4f2e-a4ed-ef0426c174dcn%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/CAGabyPq-%3D6h3%2BDUi02aWbpPMoMrd5D6dVByoC%2BoqFK_8e_CHtw%40mail.gmail.com.

Re: [go-nuts] How to cross-compile Go 1.19 compiler for Solaris 11 on Linux

['Sean Liao' via golang-nuts]

The bootstrap process is a chain of builds that each build the next stage,
to minimize any effects of the host system, in order to produce a
consistent final artifact.
Your builds are failing before it has successfully built the final host
stage, cross compiling hasn't come into the picture yet.
Where it fails is the (optional) cgo part, you'll want to fix that before
attempting to cross compile.

- sean

On Sat, Aug 27, 2022, 18:16 Shane  wrote:

> I noticed bootstrap.bash just calls make.bash here
> ,
> and make.bash runs go build with the GOOS and GOARCH set to empty strings
> here
> .
>
> Does this mean that whatever I set for GOOS when I run either
> boostrap.bash or make.bash is always ignored?
>
> On Saturday, August 27, 2022 at 12:53:48 PM UTC-4 Brian Candler wrote:
>
>> On Saturday, 27 August 2022 at 17:10:21 UTC+1 Shane wrote:
>>
>>> Is it expected that linux_syscall.c would be compiled when the GOOS
>>> environment variable is set to solaris?
>>
>>
>> I see the log output does include this line:
>>
>> Building packages and commands for host, linux/amd64.
>>
>> Although I'm not sure why it couldn't use the existing toolchain directly.
>>
> --
> 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/d797bdf4-e0c8-4096-a54d-be792ed50a90n%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/CAGabyPptmrHBdtyFxsypaOqRGwKngDU6v3Yr1eTT3KWAGrr0Ug%40mail.gmail.com.

Re: [go-nuts] Client Cipher Order Preference not being honored with golang 1.17+

['Sean Liao' via golang-nuts]

Given that Lucky 13 and other CBC attacks are more real (common,
practical), Go's decision to lower their priority didn't seem unreasonable.

Collapsing a multi dimensional protocol into an ordering requires some
value judgement on how heavily to weigh each component, there isn't a
single correct answer.

- sean

On Fri, Aug 26, 2022, 04:23 'Diana Tuck' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I guess I need to clarify what I was trying to say here - golang 1.17+
> claims that TLS_RSA_WITH_AES_128_GCM_SHA256 is more secure than
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 CBC-SHA256 doesn't have any
> countermeasures against Lucky13, but all of the SSL tools: testssl.sh,
> SSLLabs, etc. claim the other way around because of ECDHE.
>
> So in intentionally handling the cipher ordering, it seems like this
> change unintentionally made things less secure, at least according to
> several other reputable security resources. Who's correct here?
>
> On Thursday, August 25, 2022 at 1:30:11 PM UTC-7 Diana Tuck wrote:
>
>> Yes, I'm aware it's intentional, but it causes a lower security grade on
>> SSLLabs <https://ssllabs.com/>.
>>
>> On Thu, Aug 25, 2022 at 1:20 PM 'Sean Liao' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> This is intentional, see https://go.dev/issue/45430
>>>
>>> - sean
>>>
>>> On Thu, Aug 25, 2022, 19:07 'Diana Tuck' via golang-nuts <
>>> golan...@googlegroups.com> wrote:
>>>
>>>> Since upgrading to 1.17 in which the cipher order is determined by the
>>>> golang lib, clients that previously negotiated with more secure ciphers are
>>>> now using less secure ciphers.
>>>>
>>>> We see that Windows 7 and 8 clients can no longer negotiate using xc027
>>>> and are instead using 0x9c, which is lower in both of their preference
>>>> order.
>>>>
>>>> On 1.16, using testssl.sh, for example:
>>>>
>>>>  IE 11 Win 7 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH
>>>> (P-256)
>>>>  IE 11 Win 8.1   TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH
>>>> (P-256)
>>>>  IE 11 Win Phone 8.1 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH
>>>> (P-256)
>>>>  IE 11 Win 10TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH
>>>> (P-256)
>>>>
>>>> And since upgrading to 1.17 (and 1.18):
>>>>
>>>> IE 11 Win 7 TLSv1.2 AES128-GCM-SHA256, No FS
>>>> IE 11 Win 8.1   TLSv1.2 AES128-GCM-SHA256, No FS
>>>> IE 11 Win Phone 8.1 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH
>>>> (P-256)
>>>> IE 11 Win 10TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH
>>>> (P-256)
>>>>
>>>> Win 7
>>>> <https://www.ssllabs.com/ssltest/viewClient.html?name=IE=11=Win%207=95>
>>>>  and
>>>> Win 8.1
>>>> <https://www.ssllabs.com/ssltest/viewClient.html?name=IE=11=Win%208.1=134>
>>>>  prefer
>>>> 0xc027 over 0x9c, but now both negotiate using 0x9c.
>>>>
>>>> We could theoretically solve this by removing 0x9c from our supported
>>>> cipher suites to force the selection of 0xc027, but  unfortunately we
>>>> need to keep supporting these older clients.
>>>>
>>>> I wanted to check here to see if anyone has any suggestions before
>>>> filing a bug, because in my opinion, the client cipher suite order
>>>> preference should be honored at the very least even if the server
>>>> preference is no longer honored.
>>>>
>>>> --
>>>> 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/726cacb3-ddf3-4602-8455-4eae9889f236n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/golang-nuts/726cacb3-ddf3-4602-8455-4eae9889f236n%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/EqtkbU9nXHE/unsubscribe.
>>> To unsubscr

Re: [go-nuts] Client Cipher Order Preference not being honored with golang 1.17+

['Sean Liao' via golang-nuts]

This is intentional, see https://go.dev/issue/45430

- sean

On Thu, Aug 25, 2022, 19:07 'Diana Tuck' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Since upgrading to 1.17 in which the cipher order is determined by the
> golang lib, clients that previously negotiated with more secure ciphers are
> now using less secure ciphers.
>
> We see that Windows 7 and 8 clients can no longer negotiate using xc027
> and are instead using 0x9c, which is lower in both of their preference
> order.
>
> On 1.16, using testssl.sh, for example:
>
>  IE 11 Win 7 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
>  IE 11 Win 8.1   TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
>  IE 11 Win Phone 8.1 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
>  IE 11 Win 10TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH
> (P-256)
>
> And since upgrading to 1.17 (and 1.18):
>
> IE 11 Win 7 TLSv1.2 AES128-GCM-SHA256, No FS
> IE 11 Win 8.1   TLSv1.2 AES128-GCM-SHA256, No FS
> IE 11 Win Phone 8.1 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
> IE 11 Win 10TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH
> (P-256)
>
> Win 7
> 
>  and
> Win 8.1
> 
>  prefer
> 0xc027 over 0x9c, but now both negotiate using 0x9c.
>
> We could theoretically solve this by removing 0x9c from our supported
> cipher suites to force the selection of 0xc027, but  unfortunately we
> need to keep supporting these older clients.
>
> I wanted to check here to see if anyone has any suggestions before filing
> a bug, because in my opinion, the client cipher suite order preference
> should be honored at the very least even if the server preference is no
> longer honored.
>
> --
> 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/726cacb3-ddf3-4602-8455-4eae9889f236n%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/CAGabyPrJ56%3DPd0Du1ooVd9dx-CA3N%3DNkHN46OaHfFTC7S%2B_x1A%40mail.gmail.com.

Re: [go-nuts] Go multiplexers

['Sean Liao' via golang-nuts]

yamux uses its own protocol, it doesn't speak telnet

- sean

On Sat, Aug 20, 2022, 21:31 ramki...@hotmail.com 
wrote:

> Has anyone ever used a multiplexer ?
> When creating a TCP server using multiplexer, I get an error [ERR] yamux:
> Invalid protocol version: 102 when using Telnet to connect to the server.
>
> package main
>
> import (
> "fmt"
> "net"
>
> "github.com/hashicorp/yamux"
> )
>
> func main() {
> server()
> }
>
> func server() {
>
> listener, _ := net.Listen("tcp", "0.0.0.0:1113")
> for {
>
> // Accept a TCP connection
> conn, err := listener.Accept()
> if err != nil {
> panic(err)
> }
>
> // Setup server side of smux
> session, err := yamux.Server(conn, nil)
> if err != nil {
> panic(err)
> }
>
> // Accept a stream
> stream, err := session.Accept()
> if err != nil {
> panic(err)
> }
> fmt.Println("DPOO")
>
> // Listen for a message
> buf := make([]byte, 4)
> stream.Read(buf)
> stream.Close()
> session.Close()
> }
> }
>
> --
> 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/0034b133-79c3-47e7-853a-10282a5beed5n%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/CAGabyPrgTFhN0Meh3ohtrPkJMQjBbBdX48XknNxbRyJy2YXv7Q%40mail.gmail.com.

Re: [go-nuts] Re: Generic error handling with panic, recover, and defer

['Sean Liao' via golang-nuts]

or https://github.com/dsnet/try

- sean

On Fri, Jul 29, 2022, 23:01 Nathaniel Lehrer 
wrote:

> This is similar, maybe this one is better to use?
> https://github.com/lainio/err2
>
> On Tuesday, September 21, 2021 at 1:57:38 PM UTC-7 mces...@gmail.com
> wrote:
>
>> With go 1.18 generics implementation it is now possible to provide error
>> handling functions in a fashion similar to the "try" proposal. I wrote a
>> small library that implements this approach:
>> https://github.com/mcesar/must.
>>
>> An example of usage is as follows:
>>
>> package main
>> import (
>> "fmt"
>> "os"
>> "github.com/mcesar/must"
>> )
>> func main() {
>> fmt.Println(f())
>> }
>> func f() (err error) {
>> defer must.Handle()
>> f := must.Do(os.Open("file"))
>> defer f.Close()
>> // ...
>> return nil
>> }
>>
>> This idea is not new, but I think it is worthwhile to have an
>> implementation to experiment with.
>>
> --
> 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/4e492605-7922-4155-9efc-5521a9ecc6e4n%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/CAGabyPqVztBHMNj0sKJ99g19x2XZ%3Dz996NbxTyx5_g3u76dBiw%40mail.gmail.com.

Re: [go-nuts] ListenAndServeTLS() (pem and key files for private network)

['Sean Liao' via golang-nuts]

> using a self-signed certificate

> without the browser complaining that the certificate is invalid

By default, browsers trust certificates signed by Certificate Authorities
(CA) in the system cert store. CAs can get added if they pass certain
requirements. Typically they will only sign certificates after you've
demonstrated control over a domain name, either with a public HTTP or TLS
server or with DNS records. Running in a private network, you could use the
DNS option, but all certs issued this way will be logged publicly via
Certificate Transparency.

If you have some control over the end (clients) systems, you could instead
add your own CAs to the system cert store. This will allow you to sign
certificates for any address (domain or IP), at the cost of needing to
distribute the CA certificates to all your systems.

ACME is the standard protocol to automate signing certificates by
demonstrating control, if you run your own compatible CA in within your
private network, you can do this without leaking information to the public.

Unless you wish to distribute each self signed certificate to every client,
by definition they cannot be trusted by default.


- sean

-- 
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/CAGabyPq3y5VTKx7dg8sUd-wEJpVTi7HZHyJ0ofG3X1JEGLWWVQ%40mail.gmail.com.

Re: [go-nuts] Query regarding net/http/cookiejar: Cookies() method and Expiry/MaxAge

['Sean Liao' via golang-nuts]

Implement your own cookie jar,

See also:
https://github.com/golang/go/issues/19291#issuecomment-282576908

- sean


On Wed, Jun 29, 2022 at 11:31 PM Amit Saha  wrote:

> Hi all,
>
> Currently the Cookies() method as explained at
> https://pkg.go.dev/net/http/cookiejar#Jar.Cookies only adds the Name and
> Value of the cookies and strips out the MaxAge and Expires field (and all
> other fields). Presumably, as I can see in the code, the logic is if a
> cookie is returned as a return value from this method, that means, the
> cookie is valid  - expiry date is in the future, for example.
>
> In the context of testing my HTTP handler, I wanted to make sure that the
> expiry of a certain cookie is set to a specific time in the future.
>
> However, the above implementation doesn't make it possible. Is that a fair
> expectation to have that the cookiejar's Cookies() method will preserve the
> Expires/MaxAge field of the cookie so that I can verify my HTTP handler
> function logic? Or is there another alternative suggestion?
>
> Thanks,
> Amit.
>
>
>
>
>
> --
> 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/CANODV3%3D6jUAAsKSkJ3iz5t3U6NH2EDSq0jRG02gmPBYd46Afew%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/CAGabyPrVu4%3DC_KLvC_DkQpuw4KSkSSryUagdD1jZ05Ufa8WRoQ%40mail.gmail.com.

Re: [go-nuts] defer func running timing

['Sean Liao' via golang-nuts]

Maybe it's clearer if you look at what's happening like this
https://go.dev/play/p/jAia9OPJfbY

The arguments to defer are evaluated immediately, but the execution only
happens later

- sean

On Sat, Jun 25, 2022, 21:40 Lee Chou  wrote:

> Hello,
>
> https://go.dev/play/p/J1tVplkIrjt
>
> why o1.Ref print `2` but p1.Ref print `1` ?
> why o1.Ref print `2` but o2.NonRef print `3` ? it's so confused.
>
> --
> 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/19cbb40a-b21a-4dd5-964d-7921095de33dn%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/CAGabyPpLfXR4iXhzV9G0ewvYm%3DQX2R9Rg5Lva7fcybkTTxmomA%40mail.gmail.com.

Re: [go-nuts] godoc and 1.19 "Doc links"

['Sean Liao' via golang-nuts]

I believe the answer is using godoc
That would be a correct link if you used pkgsite
godoc is deprecated as of https://github.com/golang/go/issues/49212


- sean

On Sat, Jun 25, 2022, 20:54 TheDiveO  wrote:

> Using go1.19beta1 I installed godoc using "go1.19beta1 install
> golang.org/x/tools/cmd/godoc@latest". Then I tried to create a "Doc link"
> as per https://tip.golang.org/doc/comment, section heading "Doc link",
> running a godoc server on localhost:6060.
>
> In package documentation for github.com/thediveo/whalewatcher I want to
> reference the Watcher interface in package
> github.com/thediveo/whalewatcher/watcher.
>
> At first, I tried "[watcher.Watcher]": this gets rendered as non-linked
> text "[watcher.Watcher]". On a side note, the modules root package does not
> import the watcher package, if that might be somehow of importance?
>
> Then I tried "[github.com/thediveo/whalewatcher/watcher.Watcher]": this
> now gets renderes as a link to
> http://localhost:6060/github.com/thediveo/whalewatcher/watcher#Watcher --
> but this link is invalid, the correct link should instead should include
> "/pkg" ...
> http://localhost:6060/pkg/github.com/thediveo/whalewatcher/watcher#Watcher
> .
>
> What am I doing wrong? Besides using godoc, that is...
>
> --
> 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/1d174ac3-ac39-494e-b9ba-b2ff45d52b7an%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/CAGabyPqbdRZ-V0A3HZ7_Jv%2BipqDjwwYjPZyrGDCf1Ri3iapEAg%40mail.gmail.com.

Re: [go-nuts] How does Go runtime decide minimum number of threads?

['Sean Liao' via golang-nuts]

from runtime:

> The GOMAXPROCS variable limits the number of operating system threads
that can execute user-level Go code simultaneously. There is no limit to
the number of threads that can be blocked in system calls on behalf of Go
code; those do not count against the GOMAXPROCS limit.

- sean

On Mon, Jun 20, 2022, 23:26 Rahul Tiwari  wrote:

> I have intentionally set a max limit on the number of threads which can be
> spawned by my Go program to be 1 and the Go runtime errors out that it
> exceeds 1-thread limit.
> I've checked the entire code of runtime but couldn't find how the minimum
> threshold of threads to be spawned is decided. Any pointers?
>
> ```
> *package main*
>
> *import (*
> *"fmt"*
> *"runtime/debug"*
> *)*
>
> *func main() {*
> * debug.SetMaxThreads(1)*
> * fmt.Println("Hello world!")*
> }
> ```
>
>
>
> --
> 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/3c14a0f8-7363-4183-9b0d-781d72e6ef8fn%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/CAGabyPrH0hy2xhVp40CNOfQjByW-kPUZjy%3Dk3RPcLTKzQ8Jewg%40mail.gmail.com.

Re: [go-nuts] Help with sync.Cond failing to signal

['Sean Liao' via golang-nuts]

sync.Cond does not affect goroutine scheduling priority, and Signal only
makes the waiting goroutine available to be scheduled, but not force it to
be.
After a Signal() (and Unlock()), every other waiting worker and the flusher
then contends (fairly) for the lock.
What you want appears a better fit for either channels (send everything to
the flusher) or just inlining the check+flush logic into writeEvent,
essentially a proper serialization of events

See also: https://github.com/golang/go/issues/21165
> On top of that, condition variables are fiendishly difficult to use: they
are prone to either missed or spurious signals [citation needed]

- sean


On Sat, Jun 11, 2022 at 3:27 PM Kevin Burke  wrote:

> Hi,
> Recently I inherited some code in production that was hitting an error
> case that I didn't think should be possible to hit. I reduced it down to
> this test case. To be clear, there are several different ways to improve
> the code here, but I'd like to understand why it's behaving the way it does
> first.
>
> You should be able to just do "go test ." here to reproduce the error:
> https://github.com/kevinburke/sync-cond-experiment
>
> What the code is doing:
>
>- Multiple different goroutines are taking a sync.Cond lock and then
>appending data to a shared buffer.
>- A "flush" goroutine calls sync.Cond.Wait() to wait for an incoming
>signal that data has been appended
>- Each goroutine that appends to the buffer calls Signal() after the
>write, to try to wake up the "flush" goroutine
>
> I *expect* that the flush goroutine will wake up after each call to
> Signal(), check whether the batch is ready to be flushed, and if not go
> back to sleep.
>
> What I see instead is that lots of other goroutines are taking out the
> lock before the flush goroutine can get to it, and as a result we're
> dropping data.
>
> I didn't expect that to happen based on my reading of the docs for
> sync.Cond, which (to me) indicate that Signal() will prioritize a goroutine
> that calls Wait() (instead of any other goroutines that are waiting on
> sync.Cond.L). Instead it looks like it's just unlocking any goroutine?
> Maybe this is because the thread that is calling Signal() holds the lock?
>
> Thanks for your help,
> Kevin
>
> --
> 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/d7e17b2f-159c-4124-a023-eb2cdb8ba423n%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/CAGabyPp2U8yYi8FqWGC-urb4zGU4e1F33AxMekvxofjMHeCbeg%40mail.gmail.com.

Re: [go-nuts] unrecognized import path "code.google.com/p/go.crypto/openpgp"

['Sean Liao' via golang-nuts]

Note that x/crypto/openpgp has been frozen and deprecated, you're better
off with a third party maintained package

- sean

On Fri, Jun 10, 2022, 00:41 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Thu, 2022-06-09 at 14:21 -0700, Peter Sjolin wrote:
> > I attempted to use "code.google.com/p/go.crypto/openpgp" in my
> > project and got the following error:
> > $ go get code.google.com/p/go.crypto/openpgp
> > go: unrecognized import path "code.google.com/p/go.crypto/openpgp":
> > parse https://code.google.com/p/go.crypto/openpgp?go-get=1: no go-
> > import meta tags (meta tag github.com/golang/go did not match import
> > path code.google.com/p/go.crypto/openpgp)
> >
> > Is there an update to this?
> >
> > Peter
>
> This now lives here golang.org/x/crypto/openpgp (code.google.com closed
> down years ago).
>
> Dan
>
> --
> 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/1039ac47088072ae6a877aabf101d4f7984de35d.camel%40kortschak.io
> .
>

-- 
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/CAGabyPphVEXa21kZ872hFNYXaNgUhG4t3-5F7gAq9jHRME-ttQ%40mail.gmail.com.

Re: [go-nuts] Functions vs Methods: explain reasoning behind STD

['Sean Liao' via golang-nuts]

Namespacing, aesthetics, and interfaces
If, for whatever reason, you don't like the way method calls look, you can
use:

var a net.TCPAddr
_ = a.Family() // usual method call
_ = net.TCPAddr.Family() // equivalent to above

If everything was a pure function, it'd look much like the second version
anyway, especially if there are multiple types that expose similar
functionality

ref: https://go.dev/ref/spec#Method_expressions

- sean


On Thu, Jun 2, 2022 at 3:38 PM Deividas Petraitis 
wrote:

> Background: when I am writing code mostly I end up with some clunky
> solutions I am not happy with and one of the reasons I think is that I
> might be mixing funcs vs methods.
>
> So the question is basically the title.
>
> I have searched both in this group ( without a luck )  and in the Internet
> for possible ideas/answers and I end up with following points:
>
> 1. Structs are for representing things, they are things
> 2. Funcs are for performing actions, calculating things
> 3. Methods for performing actions on thing state
> 4. Methods to satisfy interface
>
> Based on these points, let's have a "thing":
>
> ```
> type Person struct {
>weight float32 // pounds
>height float32 // inches
> }
> ```
>
> And calculate BMI:
>
> ```
> func CalculateBMI(weight float32 height float32) float32 {
>  return weight / (height * height) x 703
> }
>
> p := Person{157, 66}
>
> CalculateBMI(p.weight, p.height)
> ```
>
> However if I would want for example to implement some kind of interface I
> would be forced to use method over func, but it looks weird to me for some
> reason:
>
> ```
> interface BMICalculator {
> CalculateBMI() float32
> }
>
> // Satisfies BMICalculator
> func (p * Person) CalculateBMI() float32 {
>  return p.weight / (p.height * p.height) x 703
> }
> ```
>
> For example when looking at this STD code I am not longer to reason about
> choices funcs vs methods based on points above:
> https://cs.opensource.google/go/go/+/master:src/net/tcpsock_posix.go;l=26;drc=8a56c7742d96c8ef8e8dcecaf3d1c0e9f022f708
>
> Why `(a
> 
>  *TCPAddr
> 
> ) family
> ()`
> is implemented as a method when it can be implemented as pure func like:
>
> ```
> func Family
> 
> (a
> 
>  *TCPAddr
> )
> int
> 
> {
>if a
> 
> == nil || len(a
> 
> .IP
> )
> <= IPv4len
> 
> {
>return syscall .AF_INET
> 
>}
>if a
> 
> .IP
> 
> .To4
> ()
> != nil {
>return syscall .AF_INET
> 
>}
>return syscall .AF_INET6
> 

Re: [go-nuts] uber handler to collect stacktrace when program crashing

['Sean Liao' via golang-nuts]

I believe this is asking for a single handler that will apply to all
goroutines, to which the answer is no such feature exists

- sean

On Sat, May 28, 2022, 03:09 Ian Lance Taylor  wrote:

> On Fri, May 27, 2022 at 10:42 AM Aggarwal Sre 
> wrote:
> >
> > Is there a recommended pattern besides adding a defer call ( with
> recover call, to collect debug stack trace) to each goroutine, for
> collecting a stack trace when a golang is crashing due to any sort of panic.
> >
> > In other words, is there a way to register an uber handler ( probably
> using OS signals) at the main function level, to indicate that a golang
> program crashed and stacktrace to clearly specify where exactly?
>
> A panic handle is run at the bottom of the stack.  If you write this:
>
> defer func() {
> if recover() != nil {
> fmt.Printf("%s", debug.Stack())
> }
> }()
>
> in your main function, it will print a stack trace showing the point
> of the panic.
>
> 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/CAOyqgcV4d9HxDbdp_in95j6aKFF_m%2BN_hFdeyUMuMOWRt5%2B6dw%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/CAGabyPoRyv63ztmyrAGkuQ4u8Dcqffo4dUVo6H%3DczLU7%3DvsVcw%40mail.gmail.com.

Re: [go-nuts] Re: Installing a package with an associated command

['Sean Liao' via golang-nuts]

`go install github.com/your/repo/cmd/...@latest` should work

replace `latest` with specific versions (eg prereleases) if necessary

- sean

On Wed, May 25, 2022, 08:50 christoph...@gmail.com <
christophe.mees...@gmail.com> wrote:

> Indeed, it works. What if there are multiple binaries to install ? Does
> the user have to type the full package name for each program he want to
> install ?
>
> Isn’t there an equivalent to "go install ./..." that installs everything
> in one simple and short instruction ?
>
> Le mercredi 25 mai 2022 à 08:40:04 UTC+2, Volker Dobler a écrit :
>
>> If you want the command to be installed: Why don't you install
>> _the_ _command_ with
>> go install https://github.com/chmike/clog/cmd/clogClr@latest
>> ? (Note that there is no need to install the package.)
>>
>> V.
>>
>> On Wednesday, 25 May 2022 at 08:13:58 UTC+2 christoph...@gmail.com wrote:
>>
>>> I have a small package (https://github.com/chmike/clog) that also
>>> contains a command in the cmd subdirectory (clogClr). How do I install
>>> the clog package and the command ?
>>>
>>> When I execute "go install github.com/chmike/clog@latest" I get the
>>> error message that it is not a main package. When I use go get that package
>>> is installed, but not the command (clogClr).
>>>
>>> I understand that for security purpose installing a package should not
>>> automatically install an executable binary.
>>>
>>> For now I do a git clone and a "go install ./...". It's fine for me, not
>>> for an end user. I assume there is a better way.
>>>
>> --
> 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/58eb2ba5-b44c-45b5-909e-b6cf85c65bd8n%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/CAGabyPrAPLTmAo6_31_N%3DNTNM%2BCXsfu-DhfAFCpB40DTktwYpA%40mail.gmail.com.

Re: [go-nuts] encoding/json doesn't find marshal/unmarshal via type aliases

['Sean Liao' via golang-nuts]

As explained above, `type AliasedDate Date` clears any methods you have
defined on `Date`.
But `Date` embeds `time.Time` which has its own `UnmrshalJSON`,
which now gets promoted.

So `Date.UnmsrshalJSON` calls your `UnmsrshalJSON`
`AliastedDate.UnmsrshalJSON` calls `AliastedDate.Time.UnmsrshalJSON`

On Fri, May 20, 2022 at 3:14 PM Marcin Romaszewicz 
wrote:

> Sorry about mixing up terms, however, my question still stands.
>
> encoding/json looks for the Marshaler/Unmarshaler interface
> convertibility, and in this case, the compiler thinks that the redeclared
> type does implement json.Unmarshaler. I extended my example to also do this
> test via reflection.
>
> https://go.dev/play/p/TrxM2zxG2pX
>
> So, yes, it's a new type, but it seems to behave just like the base type.
>
> On Fri, May 20, 2022 at 12:35 AM Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
>
>> It's not an "aliased type". Type aliases take the form
>> type A = B
>> and they make the name A be interchangeable with the name B. What you
>> have is a type declaration
>> type A B
>> which creates a fully new type, with a new method set, but the same
>> underlying type as B.
>>
>> On Fri, May 20, 2022 at 9:28 AM Marcin Romaszewicz 
>> wrote:
>>
>>> Hi All,
>>>
>>> I've created a simple struct that wraps time.Time because I'd like to
>>> unmarshal it differently from JSON than the default. It works great.
>>>
>>> However, when I pass a type alias of that struct to json.Marshal or
>>> json.Unmarshal, the MarshalJSON and UnmarshalJSON functions aren't invoked,
>>> despite both types conforming to the interfaces.
>>>
>>> Here's the shortest example I could make.
>>> https://go.dev/play/p/pETWQB3CWxV
>>>
>>> This is where this came up:
>>> https://github.com/deepmap/oapi-codegen/issues/579
>>>
>>> I did find a workaround, in redeclaring the MarshalJSON/UnmarshalJSON on
>>> the aliased type, but I don't understand why this is necessary, and I'm
>>> hoping someone who understands the innards of this better than I do could
>>> enlighten me.
>>>
>>> Thanks,
>>> -- Marcin
>>>
>>>
>>> --
>>> 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%2Bv29LuOa9sHFWxPxqYq_HtiQZ6_pUhCtMUOAL8Yq1X_UvyjJw%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/CA%2Bv29LvC7NY-wGXX9JUQAcGPohLB_puPz0F2Nehsq7Xx2zAZeg%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/CAGabyPpyzxzpqNy%3DqFo3pdRp2HT8Gks-xSB9e7KLmEVG%3DTb%2Bwg%40mail.gmail.com.

Re: [go-nuts] OAuth2 HttpClient customizable header

['Sean Liao' via golang-nuts]

Now that I think about it, it won't work
because oauth2 will Set the Authorization header,
overwriting whatever you might have originally set there.

Maybe it's easier to follow standard oauth and move the original user
authentication into some other header?


On Wed, May 18, 2022 at 8:50 PM 'Patrick Kaeding' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Thanks Sean!
>
> I just realized I cited the wrong package in my earlier message. I meant
> to refer to the  golang.org/x/oauth2/clientcredentials client. I'm not
> sure if that matters for the discussion, but I apologize for any confusion.
>
> Is it safe to use a custom transport with this client?
> https://pkg.go.dev/golang.org/x/oauth2@v0.0.0-20220411215720-9780585627b5/clientcredentials#Config.Client
> warns specifically against modifying the returned Client or Transport.
>
> On Wednesday, May 18, 2022 at 3:08:26 PM UTC-4 se...@liao.dev wrote:
>
>> doesn't sound like a common use case, might be easier to use a transport
>> that moves the header?
>>
>> - sean
>>
>> On Wed, May 18, 2022, 19:52 'Patrick Kaeding' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> Would it be possible to allow the [header that is used](
>>> https://github.com/golang/oauth2/blob/2e8d9340160224d36fd555eaf8837240a7e239a7/token.go#L80)
>>> by the golang.org/x/oauth2 client to be overridden?
>>>
>>> I imagine the code change would be simple, but would it be accepted?
>>>
>>> My use case is that I have an application that proxies some requests to
>>> another service. Those proxied requests have an authorization header, which
>>> is sent by their client, and identifies who that caller is. My inner
>>> service is the one that I am using the oauth2 library to authenticate with:
>>>
>>> client --API token in authorization header--> outer service --OAuth2
>>> token--> inner service
>>>
>>> The API token alone is not enough to grant access to the inner service's
>>> resource; only the outer service is authorized to access it. I'm sure I
>>> could change the way we handle the proxied request, but it seems like it
>>> would be useful to make the header customizable.
>>>
>>> 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/be9baa89-98fa-44d7-9389-6e68d8548779n%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/ef3ad422-3094-4a0a-814a-32555fc4b8e4n%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/CAGabyPpBW__%2BeYU4cyJ0kx3q10YZp6ahCSJPgvkDQs%3DpCixk_g%40mail.gmail.com.

Re: [go-nuts] OAuth2 HttpClient customizable header

['Sean Liao' via golang-nuts]

doesn't sound like a common use case, might be easier to use a transport
that moves the header?

- sean

On Wed, May 18, 2022, 19:52 'Patrick Kaeding' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Would it be possible to allow the [header that is used](
> https://github.com/golang/oauth2/blob/2e8d9340160224d36fd555eaf8837240a7e239a7/token.go#L80)
> by the golang.org/x/oauth2 client to be overridden?
>
> I imagine the code change would be simple, but would it be accepted?
>
> My use case is that I have an application that proxies some requests to
> another service. Those proxied requests have an authorization header, which
> is sent by their client, and identifies who that caller is. My inner
> service is the one that I am using the oauth2 library to authenticate with:
>
> client --API token in authorization header--> outer service --OAuth2
> token--> inner service
>
> The API token alone is not enough to grant access to the inner service's
> resource; only the outer service is authorized to access it. I'm sure I
> could change the way we handle the proxied request, but it seems like it
> would be useful to make the header customizable.
>
> 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/be9baa89-98fa-44d7-9389-6e68d8548779n%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/CAGabyPoPPOFyomB2pv5ogrtUydbADYCuO_VV5Co%2BczssxLeDxQ%40mail.gmail.com.

Re: [go-nuts] Crypto/tls: Get further information on established TLS connection

['Sean Liao' via golang-nuts]

tls.Conn.ConnectionState().PeerCertificates

- sean

On Mon, May 9, 2022, 16:59 J. Pecholt  wrote:

> Hi there,
> I am trying to perform further authentication operations based on an
> existing tls.Conn without modifying the package/module itself because of
> portability and security reasons. More precisely, I want to know on the
> server side if the client actually used a certificate to establish an
> optional mTLS connection and if so, I need a reference to said certificate.
> Alternatively, I could force mTLS, however I would still need reference to
> the certificate. I can see that in the tls.Conn struct there is an
> unexported field called peerCertificates.
>
> // A Conn represents a secured connection.
>
> // It implements the net.Conn interface.
>
> type Conn struct {
>
>// constant
>
>...
>
>peerCertificates []*x509.Certificate
>
> Access to this field/value would basically solve everything for me as the
> current connection is basically a blackbox (probably rightfully so, because
> less access means fewer ways to mess it up).
> My question is: would it make sense to propose a code addition where I
> could obtain these certificates or is there any potentially negative
> consequence to providing the certs that I’m not seeing? This could be
> similar to the function RemoteAddr() provided by the net.Connection
> interface... Alternatively, is there another module/package that solves
> 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/35a1d230-a803-46bb-92f6-2e0242f8ae03n%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/CAGabyPqhZ9KmMYnmDPjX6oqqZaM8SU_DFY-q0g_ALFwseFLQ6w%40mail.gmail.com.

Re: [go-nuts] Refactor to use generics to have a single Make

['Sean Liao' via golang-nuts]

right now it only works if the structs are actually identical:
https://go.dev/play/p/tMG3SYG5fLN

- sean


On Tue, May 3, 2022 at 8:06 PM sbezverk  wrote:

> Hello,
>
>
>
> I am starting to learn generics and I was wondering if the following code
> could be refactored to use genercis, in order to avoid using per type
> Make() method.
>
>
>
> https://go.dev/play/p/gE4Z6Zj19Is
>
>
>
> I have 3 identical structs, they are defined with different types and used
> in other types by their unique types. The function to create all 3 types
> can be consolidated as the actual structure of is the same.
>
>
>
> I am curious it would be possible to leverage generics for this. I have
> made an attempt but I still need to use per type Make method.
>
>
>
> Thank you and appreciate a lot your help.
>
>
>
> Serguei
>
> --
> 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/D41C14EF-35D1-434F-A719-1E8C88D90C0F%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/CAGabyPp9hirawRPWXNZ96psNaKrg8x0HPXNTM9DsH7cq1NNXDw%40mail.gmail.com.

Re: [go-nuts] Re: testing examples printing to stdout not working for global var

['Sean Liao' via golang-nuts]

Code needs to be written to be testable.
Peter is correct, you've taken a reference to an uninstrumented os.Stdout.
What you've written isn't identical wrt to the evaluation of stdout, so
can't be expected to perform identically.

-- 
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/CAGabyPp%2BhmnYMxnqT8pyC-1xJWFdnF8kS%3DLqO_HUDN4GKh_HZw%40mail.gmail.com.

Re: [go-nuts] What is the Go build cache for fuzz testing?

['Sean Liao' via golang-nuts]

testdata/fuzz is for inputs that have caused a failure and you want to keep
around so that they are ~always run, to prevent regressions.
-fuzzcache is more like a log of useful things it has tried, so it doesn't
waste resources going over the same/similar inputs
see `go help cache`

- sean


On Wed, Apr 27, 2022 at 1:36 AM will@gmail.com 
wrote:

> `go help clean` says:
>
>
>
>
>
>
> *The -fuzzcache flag causes clean to remove files stored in the Go
> buildcache for fuzz testing. The fuzzing engine caches files that
> expandcode coverage, so removing them may make fuzzing less effective
> untilnew inputs are found that provide the same coverage. These files
> aredistinct from those stored in testdata directory; clean does not
> removethose files.*
>
> What's the difference between the fuzz cache in the testdata/fuzz
> directory in your own package, and this "Go build cache for fuzz testing"?
> Is it duplicating testdata/fuzz per package? And where is 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/3a699718-196f-48b8-a414-19f6d8835d35n%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/CAGabyPoARenp18qCTXj2H8p8T5mHiRxt8c5NakTKXBTGfPriMw%40mail.gmail.com.

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

['Sean Liao' via golang-nuts]

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+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
> 
> .
>

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

Re: [go-nuts] Using an "internal" repo or org vs. vendor

['Sean Liao' via golang-nuts]

Back in 2016 the decision was "working as intended", ref:
https://github.com/golang/go/issues/16622#issuecomment-255391314

- sean


On Mon, Apr 25, 2022 at 5:58 PM 'Tim Hockin' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> We have some packages we would like to break out into their own repos,
> but which we don't really want anyone outside of our project to depend
> on.
>
> We could, of course, just document that.  But I had this thought that
> maybe Go's "internal" semantics could be applied here.  So as a test,
> we redirected go-get of `k8s.io/internal`  to a
> different github org
> (e.g. go get k8s.io/internal/foo -> github.com/k8s-internal/foo).
>
> This SEEMS to work until vendoring comes in, and we get errors like:
>
> ```
> package k8s.io/kubernetes/cmd/genkubedocs
> imports k8s.io/kubernetes/cmd/kubelet/app
> imports k8s.io/kubernetes/pkg/kubelet
> imports k8s.io/kubernetes/pkg/kubelet/images
> pkg/kubelet/images/image_manager.go:26:2: use of internal package
> k8s.io/kubernetes/vendor/k8s.io/internal/distribution/reference not
> allowed
> ```
>
> The code in `k8s.io/kubernetes/pkg/kubelet/images`
>  imports
> `k8s.io/internal/distribution/reference`
>  but vendoring renames it
> internally and now it fails the "internal" rules.
>
> Is this perceived as a bug or just a case of "too clever for our own good"
> ?
>
> Tim
>
> --
> 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/CAO_RewbsnD4sH5Mqc41du0DYSsSBsnVmGi7nmW0MJpvA06_M5Q%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/CAGabyPodYEr0EH4dygqZvgRdqt1iGsJbW1jpdJT2V-fDeYzAEQ%40mail.gmail.com.

Re: [go-nuts] Tool to check binaries for vulnerabilities

['Sean Liao' via golang-nuts]

If you only need to target 1.18+, you can use `debug/buildinfo.ReadFile`
which doesn't require shelling out to go


On Fri, Apr 15, 2022 at 7:03 AM Zhaoxun Yan  wrote:

> That sounds great! Thanks.
>
> 在2022年4月15日星期五 UTC+8 05:55:27 写道：
>
>> On Thu, 2022-04-14 at 03:05 -0700, Michel Casabianca wrote:
>> > Any comment and contribution welcome.
>>
>> Can I suggest that you use golang.org/x/sys/execabs rather than os/exec
>> in ExecCommand?
>>
>>
>> --
> 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/454f35cf-6599-4fc1-9dd2-602137d58cb6n%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/CAGabyPpo-HZgSLDNFU_fTrj%2BoMpCj2ePcUQWK3sGkFX_BZfG8w%40mail.gmail.com.

Re: [go-nuts] io.WriteString to a file panics

['Sean Liao' via golang-nuts]

> output, err := os.Create(o)
The short variable declaration you used to create `err` also shadows
`output`.

var err error
output, err = os.Create(o)


On Tue, Apr 12, 2022 at 8:53 AM Rory Campbell-Lange 
wrote:

> I have a command line programme that can output to either stdout or a
> named file. Output to stdout, as commented out in the small example below,
> works fine, but not to a named file.
>
> Attempting to write to a named file panics on go 1.17 on Linux with:
>
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x46123d]
>
> I'm confused since both os.Stdout and os.Create are *os.File types, which
> implement the Write(b []byte) (n int, err error) method which fulfils the
> io.Writer interface. I pass around io.Writer types in my programme to
> facilitate testing.
>
> I've chosen io.WriteString because it will use StringWriter on the writer
> if the writer supports this method, which may perform better than a simple
> Write.
>
> Clearly I am missing something fundamental, or I have a stupid error in my
> programme. Help very much appreciated.
>
> Thanks
> Rory
>
> package main
>
> import (
> "io"
> "log"
> "os"
> )
>
> func main() {
>
> // o := "-"// use stdin
> o := "/tmp/output.txt" // or a file
>
> var output io.Writer
> if o == "-" {
> output = os.Stdout
> } else {
> output, err := os.Create(o)
> if err != nil {
> log.Fatalf("Could not create file %s, %s", output, err)
> }
> defer output.Close()
> }
>
> _, err := io.WriteString(output, "hello")
> if err != nil {
> log.Fatal(err)
> }
> }
>
> --
> 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/YlUv/%2BH%2BHYguq4Nn%40campbell-lange.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/CAGabyPoZyBwx%2BdoVquRs9vsUJQjG46LJSk5MSLeyQpt95_0WZA%40mail.gmail.com.

Re: [go-nuts] Allow a TCP connection, but not a TLS connection based on an ACL

['Sean Liao' via golang-nuts]

abusing temporary delays like that could result in unpredictable
performance with up to a second between accepts, not something you want if
you are flooded with things you want to deny (which is what an ACL is for).

On Mon, Mar 28, 2022, 23:46 robert engels  wrote:

> You just need to return a temporary error. It should not be exiting anyway
> - unless the “done” channel is valid.
>
> ctx := context.WithValue(baseCtx, ServerContextKey, srv)
> for {
>rw, err := l.Accept()
>if err != nil {
>   select {
>   case <-srv.getDoneChan():
>  return ErrServerClosed
>   default:
>   }
>   if ne, ok := err.(net.Error); ok && ne.Temporary() {
>  if tempDelay == 0 {
> tempDelay = 5 * time.Millisecond
>  } else {
> tempDelay *= 2
>  }
>  if max := 1 * time.Second; tempDelay > max {
> tempDelay = max
>  }
>  srv.logf("http: Accept error: %v; retrying in %v", err, tempDelay)
>  time.Sleep(tempDelay)
>  continue
>   }
>   return err
>}
>
>
>
> On Mar 28, 2022, at 5:35 PM, 'Sean Liao' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> I would just add a for loop around your code and only return when you have
> a connection you want to allow, otherwise just log / pass the error
> elsewhere.
>
>
> On Mon, Mar 28, 2022 at 11:26 PM John  wrote:
>
>> I'm looking to satisfy this:
>>
>>- If you are in an ACL, you can make a TLS connection
>>- If you are not in an ACL, you can only a TCP connection, but not a
>>TLS connection*
>>
>> ** It would be better if it didn't honor TCP either, unless it is a
>> health probe*
>>
>> Basically I want to move my denials into the listener and not in the
>> http.Server handlers.
>>
>> I thought I was clever recently, trying to do this with:
>>
>> func (a *aclListener) Accept() (net.Conn, error) {
>> conn, err := a.ln.Accept()
>> if err != nil {
>> return nil, err
>> }
>>
>> host, _, err := net.SplitHostPort(conn.RemoteAddr().String())
>> if err != nil {
>> return nil, fmt.Errorf("connection's remote address(%s) could not be
>> split: %s", conn.RemoteAddr().String(), err)
>> }
>>
>> // The probe connected, so close the connection and exit.
>> if a.acls.isProbe(host) {
>> log.Printf("TCP probe(%s) connection", host)
>> conn.Close()
>> return nil, ErrIsProbe
>> }
>>
>>   // Block anything that isn't in our ACL.
>> if err := a.acls.ipAuth(host); err != nil {
>> return nil, err
>> }
>> log.Println("accepting connection from: ", conn.RemoteAddr().String())
>> return conn, nil
>> }
>>
>> aclListener implements a net.Listener and I was going to allow the TCP
>> probe from this
>> health service, but nothing more (like seeing the TLS header).
>> However, it turns out erroring on an Accept() will cause the http.Server
>> to stop.
>>
>> Of course, if this code did work, the difference between the prober and
>> non-ACL connections is the same, they both can get the TCP socket before
>> being denied.
>>
>> Does anyone know if I can achieve this in my code without getting super
>> hacky? I can see
>> some ways to that, but figured someone here might have done this in a
>> simple way.
>>
>> Cheers and 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/4ab235c1-ab52-42de-a22a-a31bde21eb0cn%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/4ab235c1-ab52-42de-a22a-a31bde21eb0cn%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/CAGabyPowCpbccC3Hr1_QYqC0qJnqsbP8W9C7z%3DU%2BPdD_%3DWxEpQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAGabyPowCpbccC3Hr1_QYqC0qJnqsbP8W9C7z%3DU%2BPdD_%3DWxEpQ%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/CAGabyPoLQr5Te5VxXpyvoZn4Cs3Lh64GKPWk%2Bk-LyQNA3KnS1w%40mail.gmail.com.

Re: [go-nuts] Allow a TCP connection, but not a TLS connection based on an ACL

['Sean Liao' via golang-nuts]

I would just add a for loop around your code and only return when you have
a connection you want to allow, otherwise just log / pass the error
elsewhere.


On Mon, Mar 28, 2022 at 11:26 PM John  wrote:

> I'm looking to satisfy this:
>
>- If you are in an ACL, you can make a TLS connection
>- If you are not in an ACL, you can only a TCP connection, but not a
>TLS connection*
>
> ** It would be better if it didn't honor TCP either, unless it is a health
> probe*
>
> Basically I want to move my denials into the listener and not in the
> http.Server handlers.
>
> I thought I was clever recently, trying to do this with:
>
> func (a *aclListener) Accept() (net.Conn, error) {
> conn, err := a.ln.Accept()
> if err != nil {
> return nil, err
> }
>
> host, _, err := net.SplitHostPort(conn.RemoteAddr().String())
> if err != nil {
> return nil, fmt.Errorf("connection's remote address(%s) could not be
> split: %s", conn.RemoteAddr().String(), err)
> }
>
> // The probe connected, so close the connection and exit.
> if a.acls.isProbe(host) {
> log.Printf("TCP probe(%s) connection", host)
> conn.Close()
> return nil, ErrIsProbe
> }
>
>   // Block anything that isn't in our ACL.
> if err := a.acls.ipAuth(host); err != nil {
> return nil, err
> }
> log.Println("accepting connection from: ", conn.RemoteAddr().String())
> return conn, nil
> }
>
> aclListener implements a net.Listener and I was going to allow the TCP
> probe from this
> health service, but nothing more (like seeing the TLS header).
> However, it turns out erroring on an Accept() will cause the http.Server
> to stop.
>
> Of course, if this code did work, the difference between the prober and
> non-ACL connections is the same, they both can get the TCP socket before
> being denied.
>
> Does anyone know if I can achieve this in my code without getting super
> hacky? I can see
> some ways to that, but figured someone here might have done this in a
> simple way.
>
> Cheers and 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/4ab235c1-ab52-42de-a22a-a31bde21eb0cn%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/CAGabyPowCpbccC3Hr1_QYqC0qJnqsbP8W9C7z%3DU%2BPdD_%3DWxEpQ%40mail.gmail.com.

Re: [go-nuts] GO routine never exits based on stop condition - unable to find the reason

['Sean Liao' via golang-nuts]

1. your generator never finished
2. your work channel still has things in it, there's no guarantee select
will choose done first
3. reading from a closed channel will give you a zero value


On Mon, Mar 28, 2022, 16:53 Gowtham Raj  wrote:

> In this example, we have a *worker*. The idea here is simulate clean
> shutdown of all go routines based on a condition.
>
> In this case, go routines get spun - based on workers count. Each go
> routine reads the channel, does some work and sends output to the
> outputChannel.
>
> The main go routine reads this output and prints it. To simulate a stop
> condition, the doneChannel is closed. Expected outcome is that select inside
> each go routine will pick this up and execute return which in turn will
> call the defer println. The actual output is that it never gets called
> and main exits.
>
> Not sure what's the reason behind this.
>
> Code at *https://go.dev/play/p/-R7Llw9X_6U
>  *
>
> Can you please help to figure out the bug in this code.
>
> --
> 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/3762b074-63c5-407e-9515-6833465dc94en%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/CAGabyPoU1ZXAi0TiURXgODR%3DEGXnwLyhO0u59R1yv2jfJrc%3DDw%40mail.gmail.com.

Re: [go-nuts] Golang Packages

['Sean Liao' via golang-nuts]

It's available if you use the generated pseudoversion as the version in the
pkgsite url . you can get it via a call to go get (which is necessary to
populate the proxy for pkgsite).
A bit difficult to demonstrate on your module as testbranch right now
points to v0.0.1 which takes precedence.

On Wed, Mar 16, 2022 at 2:54 PM Nickolas Daniel Filip <
nickolas.fi...@itsyscom.com> wrote:

> Hi!
> So what I'm trying to achieve is the following:
> I have a github repository containing my golang source code:
> github.com/nickolasdaniel/golang-ginrest
> On this repo I have 2 branches: 'main' and 'testbranch'
> I can access my source code on the pkg.go.dev as following:
> https://pkg.go.dev/github.com/nickolasdaniel/golang-ginrest
>
> This displays my latest tag which is v0.0.4
> However if I query as such:
> https://pkg.go.dev/github.com/nickolasdaniel/golang-ginrest@main
> I get the source code for the latest commit, which is good.
>
> But what if I want to do this for my 'testbranch' branch instead of 'main'?
> https://pkg.go.dev/github.com/nickolasdaniel/golang-ginrest@testbranch
> doesn't work.
>
> Any help on this please? Basically I just want to see source code of my
> 'testbranch' branch instead of 'main'.
>
> 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/a89cb276-3bc1-4607-b395-ed92239650e5n%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/CAGabyPoWD7Ncw_aDxp3GM5wCWCGVHvXJhy-Y4xveuBFB7J5BbQ%40mail.gmail.com.

Re: [go-nuts] debug.ReadBuildInfo is info.Main.Version always "(devel)"

['Sean Liao' via golang-nuts]

not yet https://github.com/golang/go/issues/50603

-- 
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/CAGabyPqVoiVr2etaQu4jCyQg7wg8AjKJH4_jHqqUS9n_rz-m0g%40mail.gmail.com.

Re: [go-nuts] go run strips symbols

['Sean Liao' via golang-nuts]

go run -ldflags="-s=false" .

-- 
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/CAGabyPpavvnG7QLwY5_GcBn4AmpW0abfip%3DTW5p-rDWRC-rj%3Dg%40mail.gmail.com.

[go-nuts] Re: workspaces tutorial query

[Sean Liao]

Fixed on tip
ref: https://go.dev/issue/51449

On Saturday, March 12, 2022 at 9:40:04 AM UTC kortschak wrote:

> I was just taking a look at the workspaces tutorial and saw that while
> the doc says that adding the local example module will result in
>
> go 1.18
>
> use (
> ./hello
> ./example
> )
>
> what actually results is
>
> go 1.18
>
> use (
> ./hello
> example
> )
>
> The behaviour is otherwise as expected, but this may confuse some
> readers given that leading dots are important in other paths used by
> the build system.
>
> Should the doc be updated or is the tool's behaviour unexpected here?
>
> thanks
> Dan
>
>
>

-- 
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/b041ee79-c97f-428d-8263-9a273fa6f64dn%40googlegroups.com.

[go-nuts] Re: Possible float64 precision problem

[Sean Liao]

It would help if your could show the actual code for both C and Go, as well 
as the input

On Wednesday, March 9, 2022 at 11:37:10 AM UTC christoph...@gmail.com wrote:

> I'm translating a scientific C program into Go that is doing some 64bit 
> floating point operations. 
>
> In this process I check that the same input yields the same output. 
> Unfortunately they don't yield the same result, though the computation is 
> simple. It is as follow. I receive a 64bit integer value. 
>
> This value is converted to float64/double, and divided by 2^64.
> The resulting number is multiplied by 1e8. 
>
> With C I get 41 6E 84 FD 00 09 90 D7, with Go I get 41 6E 84 FD 00 09 E6 
> 8E. The last 15bits are different. The computation is performed with the 
> same computer.
>
> Could it be that the C program is performing the computation with long 
> double (80 bit) precision and that Go is doing it with 64bit precision ? 
>
> Is there something I could do about it because that might be a red flag 
> for replacing the C program with a Go program.
>

-- 
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/56218a68-dea9-4f02-b8cb-c74b97a71704n%40googlegroups.com.

[go-nuts] Re: how to solve the go.mod conflict when 2 sub-modules point to break version of a common module

[Sean Liao]

Splitting the uses of a/b into their own modules/repo won't work if you 
ultimately import them into a single module.
It would be the same problem, just further down the dependency tree.

On Monday, March 7, 2022 at 7:14:17 PM UTC ian.zh...@gmail.com wrote:

>
> Thanks for your reply.
>
> It's sad that *a* and *b* are imported but not developed by my team I 
> guess I will have to split my *demo* to smaller modules to make sure *a* 
> and *b* are in a different module.
>
> I tried to have something like this,
>
> demo/
> pkg/
> onlya/
> a.go
> go.mod
> go.sum
> onlyb/
> b.go
> go.mod
> go.sum
> main.go
> go.mod
> go.sum
>
> however, in this way the top-level *go.mod* would still resolve and 
> contain *a* and *b*... I guess I will have to put *a* or *b* to its own 
> repo.
>
> On Monday, March 7, 2022 at 12:25:16 PM UTC-5 seank...@gmail.com wrote:
>
>> As a v0.x.y module, it's explicitly signaling that it may introduce 
>> incompatible changes between minor versions, as has happened here. 
>> unfortunately for you, a module can only exist at a single version within a 
>> build, so you'll have to modify your dependencies.
>> Some time ago, OpenTelemetry graduated their tracing APIs to stable (v1), 
>> committing to maintaining backwards compatibility, so you may want to look 
>> at upgrading both your dependencies to target the new, stable version of 
>> OpenTelemetry
>>
>> On Monday, March 7, 2022 at 5:02:06 PM UTC Tamás Gulácsi wrote:
>>
>>> Sorry to say, but *go.opentelemetry.io/otel 
>>> * is a dumpster fire of API breakage 
>>> and flux.
>>> I don't know other solution than modify a or b to use the same version 
>>> of otel.
>>>
>>> ian.zh...@gmail.com a következőt írta (2022. március 7., hétfő, 
>>> 17:49:17 UTC+1):
>>>
 Hi team,

 I'm working on a new package, *demo*, which has a dependency on *a*
  and *b*.

 Both *a* and *b* are pointing to `go.opentelemetry.io/otel` 
 

 *a* points to *go.opentelemetry.io/otel 
 * v0.20.0
 *b* points to *go.opentelemetry.io/otel 
 * v0.25.0

 However, the *go.opentelemetry.io/otel 
 * introduced break changes between 
 these 2 versions.
 At *v0.25.0*, it dropped some functions that exist in *v0.20.0* and 
 *v0.25.0* has some new functions.

 In my *demo*, the *go mod tidy* would point to v0.20.0, in this way, 
 it breaks the dependency of *b.*

 I tried to modify the *go.mod *of *demo* in order to find a common 
 version between *a* and *b*, but I can't 
 find such. 

 I wonder if there's a way to let *go mod* to allow specific module 
 versions for *a* and *b. *If not, what's other 
 possible ways to solve this issue?


 Looking forward to your reply.
 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/40825a3c-aae3-4873-8bdb-10465627bb2an%40googlegroups.com.

[go-nuts] Re: how to solve the go.mod conflict when 2 sub-modules point to break version of a common module

[Sean Liao]

As a v0.x.y module, it's explicitly signaling that it may introduce 
incompatible changes between minor versions, as has happened here. 
unfortunately for you, a module can only exist at a single version within a 
build, so you'll have to modify your dependencies.
Some time ago, OpenTelemetry graduated their tracing APIs to stable (v1), 
committing to maintaining backwards compatibility, so you may want to look 
at upgrading both your dependencies to target the new, stable version of 
OpenTelemetry

On Monday, March 7, 2022 at 5:02:06 PM UTC Tamás Gulácsi wrote:

> Sorry to say, but *go.opentelemetry.io/otel 
> * is a dumpster fire of API breakage and 
> flux.
> I don't know other solution than modify a or b to use the same version of 
> otel.
>
> ian.zh...@gmail.com a következőt írta (2022. március 7., hétfő, 17:49:17 
> UTC+1):
>
>> Hi team,
>>
>> I'm working on a new package, *demo*, which has a dependency on *a* and 
>> *b*.
>>
>> Both *a* and *b* are pointing to `go.opentelemetry.io/otel` 
>> 
>>
>> *a* points to *go.opentelemetry.io/otel 
>> * v0.20.0
>> *b* points to *go.opentelemetry.io/otel 
>> * v0.25.0
>>
>> However, the *go.opentelemetry.io/otel * 
>> introduced break changes between these 2 versions.
>> At *v0.25.0*, it dropped some functions that exist in *v0.20.0* and 
>> *v0.25.0* has some new functions.
>>
>> In my *demo*, the *go mod tidy* would point to v0.20.0, in this way, it 
>> breaks the dependency of *b.*
>>
>> I tried to modify the *go.mod *of *demo* in order to find a common 
>> version between *a* and *b*, but I can't 
>> find such. 
>>
>> I wonder if there's a way to let *go mod* to allow specific module 
>> versions for *a* and *b. *If not, what's other 
>> possible ways to solve this issue?
>>
>>
>> Looking forward to your reply.
>> 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/a3633b24-7755-4b49-b605-f9e24da79a77n%40googlegroups.com.

[go-nuts] Re: is url->String->Parse != url a bug?

[Sean Liao]

Expected, the percent encoded version produced by String() is semantically 
equivalent and safer than the raw space version, and also doesn't require 
storing the raw version.

On Friday, March 4, 2022 at 1:10:22 PM UTC joche...@gmail.com wrote:

> Hello,
>
> If I convert an url.URL to a string and then parse the result, am I meant 
> to get back the original url?  While playing with the new fuzzer I found 
> that in practise this is not the case,
> but I'm not sure whether this is due to bugs, or whether this is expected.
>
> The affected URLs are of course all silly urls, chosen by the fuzzer.
> Example: https://go.dev/play/p/VFe0MbBty3r
>
> All the best,
> Jochen
>
>

-- 
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/597d998f-0e58-4278-8026-be67ea7618a4n%40googlegroups.com.

[go-nuts] Re: Migrating to go modules with package name different from VCS

[Sean Liao]

See https://pkg.go.dev/cmd/go#hdr-Remote_import_paths
specifically:

> The meta tag has the form:
> 

If you serve the meta tags over HTTPS on the package path, you can point it 
to the appropriate git repo

On Wednesday, February 23, 2022 at 2:54:25 PM UTC+1 luxif...@gmail.com 
wrote:

> Hello,
>
> In my company, we are planning to migrate to go modules.
> The package name and VCS URL will be redacted for confidentiality.
>
> Our package name starts with `foobar.com/packagename` 
>  but the VCS URL to clone the repository 
> is `gitlab.corp.foobar.com/foobar-groups/packagename` 
> .
>
> We have more than 200 repositories containing multiple go packages, so a 
> package name rewrite is not an acceptable solution.
>
> What can I do for the migration? Can I use go proxy?
>
> Regards,
>

-- 
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/00fb2b93-2136-4dc1-8afb-b4ae9b0fb6bbn%40googlegroups.com.

[go-nuts] Re: go log.Println(http.ListenAndServe(...)) blocks

[Sean Liao]

https://go.dev/ref/spec#Go_statements :

> The function value and parameters are evaluated as usual 
 in the calling goroutine, but unlike with a 
regular call, program execution does not wait for the invoked function to 
complete.

http.ListenAndServe is being evaluated, but it blocks.
Only the log.Println call would run in the newly started goroutine.

On Friday, February 18, 2022 at 5:35:52 PM UTC+1 christoph...@gmail.com 
wrote:

> Hi gophers, 
>
> I hope someone can help finding out why a particular goroutine call can 
> block the main goroutine.
>
> In the following code, all "go" calls spawn off a goroutine and return as 
> expected, except for the last one that blocks the main goroutine. 
>
> Is this a bug, or am I missing something subtle or even obvious (obvious 
> to all others only of course)?
>
> package main
>
> import (
> "log"
> "net/http"
> )
>
> func main() {
> // all of these work as expected
> go http.ListenAndServe("localhost:8080", nil)
> go log.Println("goroutine")
> go func() {
> log.Println(http.ListenAndServe("localhost:8081", nil))
> }()
>
> // The following line blocks the main goroutine.
> go log.Println(http.ListenAndServe("localhost:8082", nil))
>
> log.Println("after go log.Println(http.ListenAndServe())") // 
> never prints
> select {} // remove this, and the code still never finishes
> }
>
> All three servers eventually run (try curl localhost:8080; curl 
> localhost:8081; curl localhost:8082),
>
> In the playground , the code even 
> deadlocks. 
>
> Any 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/7b55e78f-4f8e-4be6-b3ab-6e65109f6522n%40googlegroups.com.

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

[Sean Liao]

The `golang` container image sets the GOPATH directory to /go and the 
working directory to /go too.
Following GOPATH layout, source code is expected to be in directories under 
/go/src.
`/go/bin` is where binaries are installed by default, and `/go/pkg` include 
things like the module cache.
With modules, it is entirely possible to work outside of the GOPATH (as you 
most likely are doing).
In which case, a common pattern is to choose your own working directory,
eg `WORKDIR /workspace` and work in there.

On Friday, February 11, 2022 at 7:51:00 PM UTC+1 davidmic...@gmail.com 
wrote:

> 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 

Re: [go-nuts] Why Go allow function with unused arguments?

[Sean Liao]

By enforcing blanks, you'd lose the chance to name them something useful to 
tell the reader why they're ignored.
eg:
// why are the last 2 args ignored??
handleX = func(foo, bar, _, _ string) string { return foo + bar }

On Sunday, January 30, 2022 at 10:21:11 PM UTC+1 ren...@ix.netcom.com wrote:

> To the ops point, wouldn’t it be better to cause an error for unused 
> parameters unless they use the blank identifier?
>
> > On Jan 30, 2022, at 2:09 PM, 'Dan Kortschak' via golang-nuts <
> golan...@googlegroups.com> wrote:
> > 
> > On Sun, 2022-01-30 at 12:01 -0800, Kamil Ziemian wrote:
> >> Hello,
> >> 
> >> This is a question from ignorant in the meters of compilers and
> >> mediocre Go users at best, so it may be stupid.
> >> 
> >> I really like that in Go unused variable or import is compiler time
> >> error. As such I wonder why function like
> >>> func funTest(x int) int {
> >>> return 3
> >>> }
> >> is allowed? I would guess that it is possible to check if function
> >> argument is used in function body or not, so it seem plausible to
> >> forbid it.
> >> 
> >> Again, it maybe a stupid question from ignorant person. I have a lot
> >> things to learn about Go, but I'm stuck in learning about Unicode and
> >> UFT-8, so I guess it will be a long time before I can go back to
> >> learning proper Go. I read FAQ and I didn't remember answer to this
> >> question from it. This is my excuse for asking this question.
> >> 
> >> Best regards,
> >> Kamil Ziemian
> > 
> > It is necessary for methods to sometimes have parameters that are not
> > used in order for the type to satisfy an interface. Similarly, if
> > function values are being passed around the signatures will need to
> > match even if the parameters are not being used.
> > 
> > It is possible to use the blank identifier in these cases to signal
> > that a parameter is not being used and that can be linted for.
> > 
> > See https://github.com/golang/go/issues/39118 for discussion on a
> > proposal relating to 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/78c6d5db02f0f35230b60b8324189eb367cee209.camel%40kortschak.io
> .
>

-- 
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/5d91a708-e83c-4964-b6b1-7c7f6e55ce43n%40googlegroups.com.

Re: [go-nuts] Re: Should dev tools be tracked by go.mod?

[Sean Liao]

Go's dependency resolution doesn't work at that fine-grained of a level,
it works on the module (unit of versioning) graph, not the package import 
graph.
If your library is imported and used,  all the dependency versions in your 
`go.mod` participate in version selection.
This could present a problem if your tools introduce a version higher than 
what your consumer would otherwise have selected.

On Monday, January 24, 2022 at 10:45:29 PM UTC+1 sv...@redhat.com wrote:

> Hi Sean,
>
> Thanks a lot for your answer!
>
> On Mon, Jan 24, 2022 at 9:01 PM Sean Liao  wrote:
>
>> As a (hypothetical) consumer of your library, I would definitely 
>> appreciate fewer dependencies, 
>> mostly to reduce the chance of (or difficulty of resolving) conflicts 
>> with any other dependencies I may have 
>> (especially painful when incompatible v0.X.Y transitive dependencies are 
>> used).
>>
>
> Are conflicts really possible? Let's call the dependency of our internal 
> tool "foo". So, if I'm not mistaken, conflicts could not appear, because as 
> a user of our library the Go tooling would only follow the import graph, 
> and because our library is not using "foo" (only our helper tool is) it 
> would never evaluate our go.mod entry for "foo". If your own code has 
> another dependency that is using "foo", it would only evaluate the go.mod 
> file of _that_ dependency, and there is no conflict possible. Am I getting 
> this 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/cf7802e6-5b9c-4938-ad42-cedb634cd97fn%40googlegroups.com.

[go-nuts] Re: Should dev tools be tracked by go.mod?

[Sean Liao]

As a (hypothetical) consumer of your library, I would definitely appreciate 
fewer dependencies, 
mostly to reduce the chance of (or difficulty of resolving) conflicts with 
any other dependencies I may have 
(especially painful when incompatible v0.X.Y transitive dependencies are 
used).

It seems your tooling is developed in tandem with the library,
this certainly increases the draw of versioning everything together as a 
single codebase.
But If everything is in a single repo it may be reasonable to not have any 
explicit connection between the 2 modules,
after all, if the libarary module pins the tool module, then you're back to 
bringing in all its dependencies.

Most of my experience has been with external tooling, and here I prefer 
using `go install pkg@version`
over pinning with go.mod as this ensures no interference in dependency 
versions between tools,
and can be put in the same place as the other scripting that makes use of 
the tools.

On Monday, January 24, 2022 at 7:42:49 PM UTC+1 sv...@redhat.com wrote:

> Hi everyone,
>
>
> In our project we are having a dispute 
>  on a very similar topic as the 
> one raised by Rodolfo Carvalho recently 
> , 
> and input from this forum might help us to settle it.
>
> The situation:
>
> Our project  is a Go binding for a C 
> API, basically one package per C library. In order to track which C API we 
> already have a binding for, we wrote a small tool that scans both the C 
> headers and the Go code, matches them up and outputs a report. The tool is 
> used by developers and by the CI, but not by users of the Go bindings. The 
> tool does not make changes to the source code of the library, it only 
> analyses and reports on it. However, the dependencies of this tool will end 
> up in the "require" section of the general go.mod file of the whole module. 
>
> Our team has yet to come to an agreement on the best approach around 
> go.mod use in this case. The two positions are the following:
>
> 1) The tool's dependencies should also be tracked in the general go.mod 
> file.
>
> - Code dependencies are only expressed by "import" statements in the Go 
> code.
>
>- At the moment the tool is very specific to this project and not 
> usable in other projects.
>
>   - go.mod is about tracking versions, and pinning the versions of the 
> tools dependencies to the code is the right thing.
>
>- Having a separate go.mod for each internal tool makes things more 
> complicated (as also pointed out in the FAQ 
> 
> ):
>
>  * Other tools like vet and gofmt must be explicitly executed for each 
> module, "./..." doesn't work for all the code anymore.
>
>  * Precautions must be taken that the local module of the tool is 
> used, and not another version.
>
>  * In theory the general go.mod file would have to include a pinning 
> for the internal tool then (via a tools.go file).
>
>  * There might be "replace" directives necessary.
>
> 2) The tool should have its own separate go.mod file.
>
>- The tool is not part of the code base and not necessary to build the 
> Go bindings.
>
>- It feels cleaner to have a clear point of separation between the 
> library and the tool.
>
>- It avoids unnecessary downloads in some situations.
>
>- Entries in the main go.mod could falsely advertise a dependency to 
> users.
>
>- 3rd-party tools like packagers and security analysis tools might 
> incorrectly interpret go.mod entries falsely as dependencies.
>
>- If the tool will get more generic, it might be easier to remove it 
> from the repository.
>
> We are glad to hear any opinions and other recommendations on how to 
> settle the dispute. :-)
>
> Thanks,
>
> Sven (@ansiwen)
>
>

-- 
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/78600670-4e15-4de3-b74c-5609a902c853n%40googlegroups.com.

[go-nuts] Re: Go doc examples from the command line?

[Sean Liao]

nope https://github.com/golang/go/issues/26715

On Friday, January 21, 2022 at 11:38:19 AM UTC+1 steve@gmail.com wrote:

> I've been using, for example. "go doc -all encoding/csv" to display
> docs from the command line.
>
> Is there any of displaying the code examples visible from the go.dev
> site from the command line for a particular package in the std lib?
>
> -- 
> Steve Mynott 
> rsa3072/629FBB91565E591955B5876A79CEFAA4450EBD50
>

-- 
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/c5b23f4f-a53f-4477-84c8-c8834dc6f80fn%40googlegroups.com.

[go-nuts] Re: pkg.go.dev is showing module, but not its package documentation

[Sean Liao]

Nope, pkg.go.dev doesn't support type parameters yet
https://github.com/golang/go/issues/48264

On Thursday, January 13, 2022 at 10:50:18 AM UTC+1 po...@debevv.com wrote:

> Hi, I'm having a weird problem with pkg.dev.go. Recently I published a 
> module on github (https://github.com/debevv/camellia) and made pkg.dev.go 
> index it:
> https://pkg.go.dev/github.com/debevv/camellia
> The module contains two packages: `camellia`, which is the library, and 
> `main` inside a `cml` folder, a command line application.
>
> As you can see, it is not showing the documentation section. Plus, if I 
> look for the module or for the package in the search bar I can't find 
> anything.
> I tried generatig the HTML documentation with godoc and it works fine.
> I noticed that it is detecting it only as `module` but not as a `package` 
> too (I expect both tags since the module and one of the packages have the 
> same name)
>
> Am I doing something 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/650949de-8cda-4004-a179-59abaf491669n%40googlegroups.com.

[go-nuts] Re: Gradual change of package path

[Sean Liao]

You're right about the source of the error you're seeing (subfolder of root 
+ independent module).
If you just want to get rid of the error, update your versions of the 2 
modules so they both have the same view of module boundaries.
But you don't need 2 separate modules for this, 
and you probably shouldn't as your downstream consumers can now have the 2 
packages in different states of migration.
For most things (functions, types) you can just move them and provide 
either wrappers or type aliases at the old location.
It's only global variables that well be hard to move.


On Monday, December 20, 2021 at 5:39:00 PM UTC+1 mlevi...@gmail.com wrote:

> Hi all,
>
> I have a use-case which I'm not sure I'll be able to tackle using current 
> tooling but just to be sure, I'm asking here.
>
> I have a package which originally looked like:
> /
> /go.mod
> /package_name
> /other_packages...
>
> there are no go files at the root of the module, and the code that is 
> "meant" to be used (understand "exposed") is located in /package_name. The 
> /other_packages are in fact internal ones.
>
> I'm currently refactoring this all to:
> - put all go files that constitute the package we want to expose at the 
> root of the module
> - add an internal/ folder to handle not-exposed features and helpers
> - other changes like performance, more idiomatic go...
>
> The problem I have is that we need to be compatible with current code 
> using the /package_name during the process. So what I originally came up 
> with is:
>
> /
> /go.mod // for the module and main package
> /package_name // for compat, wired into new package
> /package_name/go.mod // with a single dependency -> the root of the module
> /internal/
> /internal/other_packages
> /go files for the correctly exposed new version of the package
>
> I was in the optic of updating the go.mod in /package_name regularly to 
> see if my refactoring was not breaking anything. But now `go mod` has a 
> problem: it finds the package /package_name in two different places:
> - one in /package_name/go.mod - the one that's being kept for compatibility
> - one in /, the root, which has a sub-package /package_name
>
> It feels like the problem is having two distinct go.mod, one in a 
> subfolder of the root of the module, but I have difficulties wrapping my 
> head around all that... If anyone has a clue what I should do, or what I'm 
> doing wrong, I'll be happy to take it!
>
> Thanks!
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/25bda8b6-9329-459b-902c-4f06072bda3cn%40googlegroups.com.

[go-nuts] Re: Does pkg.go.dev understand packages that use generics?

[Sean Liao]

not yet, see https://github.com/golang/go/issues/48264

On Saturday, December 18, 2021 at 4:23:30 PM UTC+1 kee...@gmail.com wrote:

> I created github.com/keep94/consume2 which is a rewrite of 
> github.com/keep94/consume using Go generics. However, the new package is 
> not showing up in pkg.go.dev.  I am wondering if pkg.go.dev is set up to 
> understand generics?

-- 
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/bc72ed01-5942-40f0-9527-3213fcaebf35n%40googlegroups.com.

[go-nuts] Re: generics: what can we do with an any type?

[Sean Liao]

when writing type parameterized code, it has to work with anything that 
could be passed to it.
but once instantiated, the type is known and it can be used with its 
concrete type

like `map` can be thought of as  declared to be `map[comparable]any`
but when you use it, the type is always known, eg. `map[string]int`
On Wednesday, December 15, 2021 at 5:39:39 PM UTC+1 Johannes Kohnen wrote:

> Hello folks, 
>
> I've stumbled over a thing and I don't understand if what I've found is 
> intentionally possible by design...
>
> https://go.dev/play/p/SIxOV1FnTzX?v=gotip 
>
> Why can I compare int with == when it was instantiated from the "any" type 
> parameter? 
>
> The origin of my question is my implementation of a left right map which 
> I've ported to generics.  While doing so I've uncovered a couple bugs in 
> Jetbrains GoLand and reported them.  Except this one, because I've 
> overlooked it and I now am confused:
>
>
> https://github.com/jwkohnen/lrmap/blob/a6b9a6715069a7ad24de7cf84fe949dd7f194c0a/lrmap_test.go#L26
>
> In this line I compare two int values with !=, and this code compiles. 
> Though, those value types were instantiated from the "any" type 
> constraint.  GoLand reports an error in that line "Invalid operation: _v != 
> v (the operator != is not defined on V)".
>
> From my reading of the generics proposal GoLand is right, but the compiler 
> says otherwise.  How exactly are the operations that are defined on an 
> "any" type inferred?
>
> Sorry if the answer is right there in the proposal; my reading 
> comprehension fluctuates wildly these days. 
>
> Cheers,
> Johannes
>

-- 
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/721e2328-e7ab-48a8-80fc-bf11a783d187n%40googlegroups.com.

Re: [go-nuts] Re: Flag fall through logic review

[Sean Liao]

I would go for something more like: https://play.golang.org/p/MyorlUwOL9s
and not bother with the intermediate checks, just read directly and report 
any issues you encounter

On Tuesday, November 16, 2021 at 3:49:54 PM UTC+1 leam...@gmail.com wrote:

> Brian, thanks! Here's the playground link: 
> https://play.golang.org/p/Ef8D4CF-kKD
>
> For the errors in lines 14-19, what other failures do you see needing to 
> be handled? I'm still not comprehending how to check for "isReadable()", 
> but that would be a useful next step. Of course, when the file is ingested 
> there will need to be error checking there, too.
>
> On lines 42-44, wouldn't the nil pointer issue be that the directory 
> didn't exist? So far the code seems to handle that, but I'm probably 
> missing a few things.
>
> Leam
>
> On 11/16/21 08:40, Brian Candler wrote:
> > (BTW, sharing your code on play.golang.org makes it easier to format 
> and read)
> > 
> > On Tuesday, 16 November 2021 at 14:11:54 UTC leam...@gmail.com wrote:
> > 
> > 
> > 14 func exists(filepath string) bool {
> > 15 if _, err := os.Stat(filepath); errors.Is(err, fs.ErrNotExist) {
> > 16 return false
> > 17 }
> > 18 return true
> > 19 }
> > 
> > 
> > You are silently ignoring all errors here, apart from fs.ErrNotExist.  
> (You already identified that problem in your isDir function).
> > 
> > Basically there are three possible results: file exists, file doesn't 
> exist, or something went wrong.  The traditional way to return that would 
> be as a pair of values (bool, err)
> > 
> > Alternatively, it might be reasonable to panic(err) on any other non-nil 
> error here.
> > 
> > 42 if exists(*custom_datadir) {
> > 43 customData = isDir(*custom_datadir)
> > 44 }
> > 
> > 
> > Screams "pointer not checked for nil" to me.
>
> -- 
> Systems Programmer (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/83aca86a-0cf0-46a1-a066-56dd4171266an%40googlegroups.com.

[go-nuts] Re: Trying to code an observer pattern or a publish/submit pattern for a cellular automaton

[Sean Liao]

that's exponential growth, every value results in 2 output values
input "1" x1, get "2" x2, "3" x4, "4" x8, "5" x16, ...
also your use of goroutines to send mean you'll still run out of memory at 
some point

On Sunday, November 14, 2021 at 2:29:26 PM UTC Serge Hulne wrote:

> Hi,
>
> I am trying to code an observer pattern or a publish/submit pattern for a 
> sort of cellular automaton.
>
> The classical observer pattern does not to the trick because if a cell A 
> subscribes to changes in a cell B and vice-versa, the application will run 
> out of stack owing to the recursive approach (B.update() will call 
> A.update() and so on and the app will run out of stack). 
>
> So I though about using a publish/subscribe pattern where respective cells 
> pass each other messages, rather than calling each other's update() methods.
>
> Here is a simple example with two cells A and B:
>
> ```
> package main
>
> import (
> "fmt"
> ps "publish/pubsub"
> )
>
> func main() {
>
> fmt.Printf("Starting\n")
>
> chEnd := make(chan int)
>
> // initialize
> a := ps.NewNode(1, 0)
> b := ps.NewNode(2, 0)
>
> // connect nodes
> a.Connect(b.ChOut)
> b.Connect(a.ChOut)
>
> // Start listening
> a.Listen()
> b.Listen()
>
> // Start sending data on one arbitrary node
> // to start the process.
> a.ChIn <- 10
>
> <-chEnd
> }
> ```
> and the corresponding lib
>
> ```package lib
>
> import (
> "fmt"
> )
>
> type Node struct {
> Id int
> State int
> ChOut chan int
> ChIn chan int
> }
>
> func NewNode(id int, state int) Node {
> chout := make(chan int)
> var chin chan int
> return Node{id, state, chout, chin}
> }
>
> func (p *Node) Broadcast(inItem int) {
> p.ChOut <- inItem + 1
> //time.Sleep(100 * time.Millisecond)
> }
>
> func (p *Node) Listen() {
> go func() {
> for {
> select {
> case inItem := <-p.ChIn:
> fmt.Printf("%d: %d\n", p.Id, inItem)
> p.Broadcast(inItem)
> }
> }
> }()
> }
>
> func (p *Node) Connect(ch chan int) {
> p.ChIn = ch
> }
> ```
> Each node has a input and an output channe.
> The input channel of B is the output channel of A and vice-versa.
>
> Every update consists merely of incrementing the data passed by the other 
> cell.
>
> It seems to work. So far, so good.
>
> I tried to with a set of 4 cells A, B, C, D, in order to simulate a one 
> dimensional cellular automaton of sorts.
>
> In this second attempt, 
>
>- each cell has two input channels (let and right) to listen to its 
>closest left- and right-hand neighbour, respectively (ChinL and ChinR).
>- each cell has to output channels to communicate its latest updated 
>state to its closest neighbours (ChoutL and ChoutR).
>
> I must have done something wrong in the implementation of that scheme with 
> 4 cells, because it yields odd results : the values passed back and forth 
> between the 4 cells seem to hit a threshold instead of increasing at every 
> consecutive step: here is the code:
>
> ```
> package main
>
> import (
> "fmt"
> ps "publish/pubsub"
> )
>
> func main() {
>
> fmt.Printf("Starting\n")
>
> chEnd := make(chan int)
>
> // initialize
> a := ps.NewNode(1, 0)
> b := ps.NewNode(2, 0)
> c := ps.NewNode(3, 0)
> d := ps.NewNode(4, 0)
>
> // connect nodes
> a.ChInL = d.ChOutR
> a.ChInR = b.ChOutL
>
> b.ChInL = a.ChOutR
> b.ChInR = c.ChOutL
>
> c.ChInL = b.ChOutR
> c.ChInR = d.ChOutL
>
> d.ChInL = c.ChOutR
> d.ChInR = a.ChOutL
>
> // Start listening
> go a.Listen()
> go b.Listen()
> go c.Listen()
> go d.Listen()
>
> go a.Broadcast()
> go b.Broadcast()
> go c.Broadcast()
> go d.Broadcast()
>
> // Start sending data on one arbitrary node
> // to start the process.
> a.ChInL <- 1
>
> // Dummy read on channel to make main() wait
> <-chEnd
> }
>
> /*
> A B C D
> LR LR LR LR
> */
>
> ```
>
> and the corresponding lib
>
> ```
> package main
>
> import (
> "fmt"
> ps "publish/pubsub"
> )
>
> func main() {
>
> fmt.Printf("Starting\n")
>
> chEnd := make(chan int)
>
> // initialize
> a := ps.NewNode(1, 0)
> b := ps.NewNode(2, 0)
> c := ps.NewNode(3, 0)
> d := ps.NewNode(4, 0)
>
> // connect nodes
> a.ChInL = d.ChOutR
> a.ChInR = b.ChOutL
>
> b.ChInL = a.ChOutR
> b.ChInR = c.ChOutL
>
> c.ChInL = b.ChOutR
> c.ChInR = d.ChOutL
>
> d.ChInL = c.ChOutR
> d.ChInR = a.ChOutL
>
> // Start listening
> go a.Listen()
> go b.Listen()
> go c.Listen()
> go d.Listen()
>
> go a.Broadcast()
> go b.Broadcast()
> go c.Broadcast()
> go d.Broadcast()
>
> // Start sending data on one arbitrary node
> // to start the process.
> a.ChInL <- 1
>
> // Dummy read on channel to make main() wait
> <-chEnd
> }
>
> /*
> A B C D
> LR LR LR LR
> */
>
> ```
>
> package pubsub
>
> import (
> "fmt"
> "strings"
> )
>
> type Node struct {
> Id int
> State int
> ChOutL chan int
> ChOutR chan int
> ChInL chan int
> ChInR chan int
> ChIO chan int
> }
>
> func NewNode(id int, state int) Node {
> choutL := make(chan int)
> choutR := make(chan int)
> var chinL chan int
> var chinR chan int
> chIO := make(chan int)
> return Node{id, state, choutL, choutR, chinL, chinR, chIO}
> }
>
> func (p 

[go-nuts] Re: compile time error vs runtime crash for same array

[Sean Liao]

global variables are stored in there data section of the compiled binary, 
the linker imposes a 2GB size limit
the array in main can be allocated at runtime, and given enough memory, it 
could succeed


On Saturday, November 13, 2021 at 5:46:29 PM UTC arthurwil...@gmail.com 
wrote:

> On a 64bit Mac, this code:
>
> package main
>
> var X [^uint(0)>>14]byte
> func main() {
> }
>
> produces a compile time error:
> main.X: symbol too large (1125899906842623 bytes > 20 bytes)
>
> But this compiles and crashes at runtime. 
>
> package main
>
> func main() {
> var X [^uint(0) >> 14]byte
> _ = X
> }
>
> runtime: out of memory: cannot allocate 1125899906842624-byte block 
> (3997696 in use)
> fatal error: out of memory
>
> goroutine 1 [running]:
> runtime.throw({0x1061335, 0x11})
> /usr/local/go/src/runtime/panic.go:1198 +0x71 fp=0xc42658 
> sp=0xc42628 pc=0x102b031
> runtime.(*mcache).allocLarge(0x100a734, 0x3, 0x11, 0x1)
> /usr/local/go/src/runtime/mcache.go:229 +0x22e fp=0xc426b8 
> sp=0xc42658 pc=0x101086e
> runtime.mallocgc(0x3, 0x1059300, 0x1)
> /usr/local/go/src/runtime/malloc.go:1082 +0x5c5 fp=0xc42738 
> sp=0xc426b8 pc=0x100a645
> runtime.newobject(0x1058a00)
> /usr/local/go/src/runtime/malloc.go:1228 +0x27 fp=0xc42760 
> sp=0xc42738 pc=0x100aa87
> main.main()
> /Users/billmorgan/git/tmp/main.go:5 +0x25 fp=0xc42780 
> sp=0xc42760 pc=0x1054c65
> runtime.main()
> /usr/local/go/src/runtime/proc.go:255 +0x227 fp=0xc427e0 
> sp=0xc42780 pc=0x102d6c7
> runtime.goexit()
> /usr/local/go/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc427e8 
> sp=0xc427e0 pc=0x1051fa1
>
>
> Why does the 2nd program succeed compilation of the same array that failed 
> compilation in the 1st program? 
>
> It was known ahead of time that the allocation would fail so I think the 
> 2nd program should have failed to compile too.
>
>
>
>
>

-- 
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/375d526e-0234-4429-971d-2ebf31d6d80dn%40googlegroups.com.

[go-nuts] Re: Correct usage of Google Api Client

[Sean Liao]

svc, err := indexing.NewService()
res, err := svc.UrlNotifications.Publish({ /* 
things in here */ }).Do()

On Monday, November 8, 2021 at 6:59:31 PM UTC+1 ladonkin...@gmail.com wrote:

> Hi,
>
> I'm new to Golang so sorry if the question seems stupid.
>
> I'm trying to inform google about a new job on my website using the 
> following documentation - 
> https://developers.google.com/search/apis/indexing-api/v3/prereqs
>
> At the end of the page they provide the instructions of how to do it using 
> different languages, but unfortunately not with Go. I found the following 
> library - https://github.com/googleapis/google-api-go-client - which 
> seems to be right for the task but I'm not sure how to use it properly - 
> all I came up with is:
>
> ctx := context.Background()
> indexingService, err := indexing.NewService(ctx)
> indexingService.BasePath = "
> https://indexing.googleapis.com/v3/urlNotifications:publish;
>
> But I don't know how to send the request or how to include the body into 
> it (and I'm not sure about the part that I wrote as well, to be honest).
>
> Maybe someone has already had some experience with it and can point me to 
> the right direction?
>

-- 
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/72bb3c7c-52ce-4130-bfe8-126197cadc8en%40googlegroups.com.

Re: [go-nuts] Various questions about posts from The Go Blog

[Sean Liao]

Blog posts should really be viewed as a snapshot that is valid when they're 
published (that's why they contain a date)
The guides under https://golang.org/doc/#getting-started however should be 
kept up to date with the latest releases

On Monday, November 8, 2021 at 11:24:48 AM UTC+1 kziem...@gmail.com wrote:

> "Technically that behaviour is still available via GO111MODULE=auto.
> Go 1.16 changed the default from "auto" to "on"."
>
> Thank you for that information. It is surprisingly hard to me to learn 
> basic of Go and Go tools, when things don't works as described.
>
> I found few another places where "Using Go Modules" (
> https://go.dev/blog/using-go-modules) is not up to date with out of box 
> Go version 1.17.2.
>
> 1) According to part "Adding a dependency" (end of fourth block of text) 
> "Only direct dependencies are recorded in the go.mod file". But my go.mod 
> file contains lines.
>
> require (
> golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c // indirect
> rsc.io/sampler v1.3.0 // indirect
> )
>
> 2) After using "go get golang.org/x/text" command "go list -m all" I get 
> one line more that in blog post
>
> golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e
>
> 3) After function TestProverb(t *testing.T) is and running "go test" (I'm 
> quite sure that when I did this few years ago, this was the command that I 
> used) I get
>
> hello.go:5:2: no required module provides package rsc.io/quote/v3; to add 
> it:
> go get rsc.io/quote/v3
>
> This is easy to solve by running "go get rsc.io/quote/v3", but still 
> annoying when you are going through this post.
>
> Best
> Kamil
> niedziela, 31 października 2021 o 00:29:57 UTC+2 Kamil Ziemian napisał(a):
>
>> This is probably silly thing, but I will write it down just in case.
>>
>> I mentioned before Go blog post "Using Go Modules" (
>> https://go.dev/blog/using-go-modules), we first write a function
>>
>> func Hello() string {
>> return "Hello, world."
>> }
>>
>> and test for it which basically check condition
>>
>> Hello() == "Hello, world."
>>
>> In the next step we change our function to
>>
>> func Hello() string {
>> return quote.Hello()
>> }
>>
>> using the module "rsc.io/quote". But this is "not portable example" and 
>> when test on my computer PASS when using the first version of our Hello() 
>> function, it FAILS with the second.
>>
>> According to description quote.Hello() (
>> https://pkg.go.dev/rsc.io/quote#Hello), but from source code we know 
>> that in fact it returns a string returned by sampler.Hello(prefs 
>> ...language.Tag). The last function "returns a localized greeting. If no 
>> prefs are given, Hello uses DefaultUserPrefs." (
>> https://pkg.go.dev/rsc.io/sampler#Hello).
>>
>> On my computer it correctly detected polish language so quote.Hello() 
>> returns "Witaj świecie." and since "Witaj świecie." != "Hello, world." the 
>> test now fails.
>>
>> Best
>> Kamil
>>
>> sob., 30 paź 2021 o 23:28 Sean Liao  napisał(a):
>>
>>> Technically that behaviour is still available via GO111MODULE=auto.
>>> Go 1.16 changed the default from "auto" to "on".
>>>
>>> On Saturday, October 30, 2021 at 11:17:05 PM UTC+2 kziem...@gmail.com 
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I don't have energy today to read Go language spec or learning how 
>>>> UTF-8 works, so I decided to make a look at Go blog post "Using Go 
>>>> Modules" 
>>>> (https://go.dev/blog/using-go-modules). I have a simple question: is 
>>>> this post up to date?
>>>>
>>>> I guess not, here is my reason why. According to it if I run command 
>>>> "go test" outside $GOPATH and in director without go.mod file I should get 
>>>> result similar to
>>>>
>>>> PASS
>>>> ok  _/some path/hello 0.020s
>>>>
>>>> When I run it with my go version go1.17.1 linux/amd64, result is
>>>>
>>>> go: go.mod file not found in current directory or any parent directory; 
>>>> see 'go help modules'
>>>>
>>>> This is one of the Go blog post listed on Documentation page (
>>>> https://golang.org/doc/), so I guess it should have note "If you use 
>>>> Go in version x.y.z

Re: [go-nuts] Various questions about posts from The Go Blog

[Sean Liao]

Technically that behaviour is still available via GO111MODULE=auto.
Go 1.16 changed the default from "auto" to "on".

On Saturday, October 30, 2021 at 11:17:05 PM UTC+2 kziem...@gmail.com wrote:

> Hello,
>
> I don't have energy today to read Go language spec or learning how UTF-8 
> works, so I decided to make a look at Go blog post "Using Go Modules" (
> https://go.dev/blog/using-go-modules). I have a simple question: is this 
> post up to date?
>
> I guess not, here is my reason why. According to it if I run command "go 
> test" outside $GOPATH and in director without go.mod file I should get 
> result similar to
>
> PASS
> ok  _/some path/hello 0.020s
>
> When I run it with my go version go1.17.1 linux/amd64, result is
>
> go: go.mod file not found in current directory or any parent directory; 
> see 'go help modules'
>
> This is one of the Go blog post listed on Documentation page (
> https://golang.org/doc/), so I guess it should have note "If you use Go 
> in version x.y.z or latter, some code may not work", but maybe I just think 
> about it in the wrong way.
>
> From practical reason this particular thing isn't important, because 
> go.mod file is the way to go (or at least this is what I read in the last 
> week).
>
> Best
> Kamil
>
> wtorek, 7 września 2021 o 22:23:19 UTC+2 Ian Lance Taylor napisał(a):
>
>> On Tue, Sep 7, 2021 at 3:40 AM Kamil Ziemian  wrote: 
>> > 
>> > In the post "Concurrency is not parallelism" by Andrew Gerrand (
>> https://go.dev/blog/waza-talk) under the paragraph starting with "To 
>> clear up this conflation, Rob Pike gave a talk at Heroku’s Waza" in my 
>> browser is big blank space. I believe that that I can see rectangle in it, 
>> with slightly different hue of with, but I can't be sure. 
>> > 
>> > Is it my browser not working or something goes wrong with the page? Can 
>> someone check if he/she has the same problem? I use Mozilla Firefox for 
>> Ubuntu canonical - 1.0, version 91.0.2 (64 bits). I hope I don't mess up 
>> Fierfox data. 
>>
>> Thanks, sent https://golang.org/cl/348013 to fix this. 
>>
>> 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/fce2cfcc-993d-4c25-8863-484b67b02870n%40googlegroups.com.

[go-nuts] Re: Amateur's questions about "Go lang spec"

[Sean Liao]

There isn't much to it, a "production_name" is just an identifier for the 
set of values defined on the other side of the =, some of which may also be 
identifiers that should be dereferenced/expanded

If it helps, there's a wikipedia entry on 
it: https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form

On Thursday, October 28, 2021 at 7:33:27 PM UTC+2 kziem...@gmail.com wrote:

> Hello,
>
> From what I understand proper Gopher read at least one time "The Go 
> Programming Language Specification" (https://golang.org/ref/spec) and now 
> I need to read it too.
>
> I learn something of Extended Backus-Naur Form to understand it, so if I 
> say something stupid beyond belief, I hope you will forgive me. In the 
> first part "Notation" (https://golang.org/ref/spec#Notation) I believe 
> that I understand meaning of all concepts except of "production_name". On 
> one hand "production_name" means that it is name of the production, not 
> rocket science here. On the other, after reading about EBNF I feel that I 
> should have more information about it. Can you explain it to me?
>
> Again I'm new to EBNF, so maybe this is stupid question.
>
> Best
> Kamil
>
>

-- 
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/18c916bf-a4b3-4ab4-a3c7-b67e925b13b9n%40googlegroups.com.

[go-nuts] Re: x/crypto/openpgp missing support for uncompressed data in compressed data packets

[Sean Liao]

Note as of https://github.com/golang/go/issues/44226 x/crypto/openpgp is 
frozen and deprecated

On Saturday, October 16, 2021 at 9:01:42 PM UTC+2 arud...@stripe.com wrote:

> Hello,
>
> I think I may have found a bug in the x/crypto/openpgp implementation. 
> However, I wanted to ask here to make sure, before filing a bug report.
>
> The gist of it is, the RFC for OpenPGP states that "Implementations MUST 
> implement uncompressed data" (source: 
> https://datatracker.ietf.org/doc/html/rfc4880#section-9.3). However, the 
> implementation in Go does not: 
> https://github.com/golang/crypto/blob/master/openpgp/packet/compressed.go#L50
>
> I encountered this issue while trying to use the OpenPGP implementation in 
> Go to read uncompressed data in a compressed data packet. For reference, 
> GnuPG seems to handle this case.
>
> I created a proof of concept to verify the bug: 
> https://gist.github.com/ajrudzitis/a6b240763f2211da9990480bbd73cfbf
>
> I was able to parse the message with GnuPG, but not Go:
>
> # off=0 ctb=c8 tag=8 hlen=2 plen=24 new-ctb
> :compressed packet: algo=0
> # off=3 ctb=cb tag=11 hlen=2 plen=21 new-ctb
> :literal data packet:
> mode t (74), created 0, name="hello.txt",
> raw data: 6 byte
>
> If other folks agree, I am happy to open an issue.
>
> Cheers,
>
> Aleks
>

-- 
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/ef10f5cc-6dd9-4f7a-b425-7ff8a8f8e277n%40googlegroups.com.

[go-nuts] Re: Problem using embed in Go 1.16

[Sean Liao]

import _ "embed"

It means to import it for side effects only

On Sunday, October 10, 2021 at 6:12:07 PM UTC+2 sunto...@gmail.com wrote:

> Hi,
>
> I'm having problem using embed with Go 1.16. I'm getting ether
>
> - //go:embed only allowed in Go files that import "embed"
> - or imported and not used: "embed"
>
> The test code is published at
> https://github.com/suntong/lang/tree/master/lang/Go/src/ds/embed
>
> here are the details:
>
> If I remove the "embed" Go import, I'll get:
>
> $ go build
> # github.com/suntong/lang/lang/Go/src/ds/embed
> ./embeding.go:17:3: //go:embed only allowed in Go files that import "embed"
>
> If I add back the "embed" Go import, I'll get:
>
> $ go build
> # github.com/suntong/lang/lang/Go/src/ds/embed
> ./embeding.go:11:2: imported and not used: "embed"
>
> $ go version
> go version go1.16.6 linux/amd64
>
> $ lsb_release -a 
> No LSB modules are available.
> Distributor ID: Debian
> Description:Debian GNU/Linux bullseye/sid
> Release:10.10
> Codename:   buster
>
> The main file:
>
> ---
> package main
>
> import (
> "embed"
> "flag"
> "fmt"
> "os"
> )
>
> //go:embed cpuArch.txt
> var cpuArch string
>
> func usage() {
> // Fprintf allows us to print to a specifed file handle or stream
> fmt.Fprintf(os.Stderr, "\nUsage: %s [flags] file [path ...]\n\n",
> "CommandLineFlag") // os.Args[0]
> flag.PrintDefaults()
> os.Exit(0)
> }
>
> func main() {
> fmt.Printf("Before parsing the flags\n")
> fmt.Printf("CPU: '%s'\n", cpuArch)
>
> flag.StringVar(, "cpu", "AMD64", "CPU Arch")
>
> flag.Usage = usage
> flag.Parse()
>
> // There is also a mandatory non-flag arguments
> if len(flag.Args()) < 1 {
> usage()
> }
>
> fmt.Printf("\nAfter parsing the flags\n")
> fmt.Printf("CPU: '%s'\n", cpuArch)
>
> }
> ---
>
>
>

-- 
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/99ac3e07-b1b6-4605-99f3-cf013a8ef8d3n%40googlegroups.com.