Re: [go-nuts] Dynamic composition of interfaces at runtime?

[cpu...@gmail.com]

Great post, thank you! Found you Wrap method looks exactly like my decorate 
:). 

While not entirely satisfying it does solve the problem and the set of 
optional methods in my case is always below 5 so the effort is manageable. 
Since the optional interfaces are really narrow (always 1 method) I guess I 
can proceed with this approach...

Kind regards,
Andi

On Wednesday, August 26, 2020 at 5:59:13 PM UTC+2 axel.wa...@googlemail.com 
wrote:

> Hi,
>
> no, there isn't really a solution to this. I've blogged about this:
>
> https://blog.merovius.de/2017/07/30/the-trouble-with-optional-interfaces.html
> A combination of generics and embedding can help. So, you can do
>
> type Wrapper[T] struct {
> T
> otherFields
> }
>
> func (w *Wrapper) SomeNewMethod() {
> }
>
> But even then, you need to know the static type of what you're wrapping 
> (so http Middleware, for example, couldn't use this).
>
> I'm also not super sure if it's a good idea to do this even if you could. 
> An interface might contain multiple, interdependent methods. As an example, 
> `http.ResponseWriter` implicitly calls `WriteHeader` the first time you 
> call `Write`. So, if you wrap a `ResponseWriter` and overwrite 
> `WriteHeader`, that overwritten method has to be called explicitly (the 
> underlying `ResponseWriter` will call its own `WriteHeader`). So if you 
> don't know what the methods of the wrapped type are and do, you might 
> introduce very hard to find bugs.
>
> On Wed, Aug 26, 2020 at 5:49 PM cpu...@gmail.com  wrote:
>
>> Hi All,
>>
>> using interfaces for behavioural testing seems a common pattern in go:
>>
>> if typed, hasCapability := d.(Capability); hasCapability...
>>
>> I have the requirement to dynamically compose interfaces at runtime, i.e. 
>> I cannot know upfront which set of interfaces a resulting type will support:
>>
>> type resultingType interface {
>> basicCapability
>> ...any combination of additional capabilities
>> }
>>
>> If there is only a single additional/optional capability to implement 
>> that is simple to solve, e.g. by implementing a wrapping struct that embeds 
>> the basic capability and adds an additional capability. Applying this 
>> pattern across multiple layers (stack of wrapping structs does not work as 
>> the embedded interfaces don't bubble up).
>>
>> However, the number of additional capabilities that a type might have to 
>> support could be bigger (think of physical meters which could supply power, 
>> energy, currents, frequency etc).
>>
>> I'm solved this by using go:generate which is fed the basic and set of 
>> optional types and generates additional types for any _combination_ of 
>> additional types, an example is attached (and source at 
>> https://github.com/andig/evcc/pull/310/files#diff-fa40c05651b4682eb25a198f8a4a98f0).
>>  
>> This is similar to the "old" pattern of simulation generics via generated 
>> code.
>>
>> I'm wondering if using a pattern of dynamic composition is sound, if the 
>> the go:generate approach is a good one or if there are better ways?
>>
>> Kind regards,
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/217cee40-1e00-442d-a4d2-7d4a37e41544n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/217cee40-1e00-442d-a4d2-7d4a37e41544n%40googlegroups.com?utm_medium=email&utm_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/bacb1b26-daf2-49b3-8d56-e9530803e6f4n%40googlegroups.com.

[go-nuts] What are the best practices for go build tools?

[cpu...@gmail.com]

Hello experts,

I'm currently using //go:generate with external and module-internal tools. 
All external tools are documented in tools.go:

// +build tools

package main

import (
_ "github.com/golang/mock/mockgen"
_ "github.com/mjibson/esc"
)

However, the existing setup has a couple of drawbacks:

1) I cannot do go install tools.go:
tools.go:6:2: import "github.com/golang/mock/mockgen" is a program, not an 
importable package
tools.go:7:2: import "github.com/mjibson/esc" is a program, not an 
importable package

instead I need to duplicate each tool installation in the Makefile

2) The internal tools are currently not installed in invoked during build:

//go:generate go run ../cmd/tools/decorate.go ...
 
This fails during cross-build:
GOOS=linux GOARCH=arm make
go install github.com/mjibson/esc
go install github.com/golang/mock/mockgen
Generating embedded assets
go generate ./...
...
fork/exec 
/var/folders/pm/q2g_c0vn1hb414nqwdcsv4fmgn/T/go-build741389459/b001/exe/decorate:
 
exec format error
charger/evsewifi.go:57: running "go": exit status 1
fork/exec 
/var/folders/pm/q2g_c0vn1hb414nqwdcsv4fmgn/T/go-build892585922/b001/exe/decorate:
 
exec format error
meter/meter.go:16: running "go": exit status 1

I've looked at https://golang.org/cmd/go/#hdr-Build_constraints but 
couldn't find a description of best practices or even mention of +built 
tools.

Much appreciated,
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/427d5e01-37de-4814-bb4d-c87b35532e1bn%40googlegroups.com.

Re: [go-nuts] What are the best practices for go build tools?

[cpu...@gmail.com]

Hi Paul!

Thank you for taking the time to reply.

On Friday, September 18, 2020 at 11:33:49 AM UTC+2 Paul Jolly wrote:

> Hi Andi, 
>
> > 1) I cannot do go install tools.go: 
>
> go install takes main packages as arguments, so no, this will not 
> work. The tools.go file (like the example you present) is simply a way 
> of declaring a dependency on a main package through a file that will 
> never be built (hence the +build tools constraint). Even though this 
> file is, in normal operation, ignored by all build commands (go build, 
> go install etc) it _is_ seen by go mod tidy (which ignores build 
> constraints). Hence the requirement is considered when collating the 
> main module's requirements. 
>
> > instead I need to duplicate each tool installation in the Makefile 
>
> If you want to install these commands then yes, this needs to happen 
> somewhere (could even be a go:generate step) 
>
> However, you can simply go run $mainpkg and this will work (see below) 
>
 
Understood. Unfortunately, that clashes with the simplistic approach to 
cross-building below.

> 2) The internal tools are currently not installed in invoked during 
> build: 
>
> Per my suggestion above, this is my preferred mechanism. It avoids any 
> unnecessary steps of ensuring the correct GOBIN, PATH etc. 
>
> > //go:generate go run ../cmd/tools/decorate.go ... 
> > 
> > This fails during cross-build: 
> > GOOS=linux GOARCH=arm make 
> > go install github.com/mjibson/esc 
> > go install github.com/golang/mock/mockgen 
> > Generating embedded assets 
> > go generate ./... 
> > ... 
> > fork/exec 
> /var/folders/pm/q2g_c0vn1hb414nqwdcsv4fmgn/T/go-build741389459/b001/exe/decorate:
>  
> exec format error 
> > charger/evsewifi.go:57: running "go": exit status 1 
> > fork/exec 
> /var/folders/pm/q2g_c0vn1hb414nqwdcsv4fmgn/T/go-build892585922/b001/exe/decorate:
>  
> exec format error 
> > meter/meter.go:16: running "go": exit status 1 
> > 
> > I've looked at https://golang.org/cmd/go/#hdr-Build_constraints but 
> couldn't find a description of best practices or even mention of +built 
> tools. 
>
> I'm not sure how you are getting into this situation, because go run 
> will build a binary for the platform on which cmd/go is running. 


> Unless you have GOOS and GOARCH set, in which case the go run during 
> the go generate phase will be building for potentially a different 
> platform? 
>

Exactly. User tried  GOOS=linux GOARCH=arm make which ended up as above. 
This can obviously be worked around by (in my case) make assets && 
GORACH/GOARM make build but it's not obvious.
 

> Paul 
>

Regards,
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/8dcfc9de-c77d-47a4-af65-314b296f5dddn%40googlegroups.com.

[go-nuts] CSS-like selectors for Go AST?

[cpu...@gmail.com]

Good morning.

I've recently found myself writing a code generator for dynamic interface 
composition at runtime. It became ugly and I had to pass in quite a number 
of parameters that should have been available from reading the source code.

In a second attempt I've reimplemented the generator using stringer-like 
AST handling. It worked well but was cumbersome to code.

Now an idea surfaced: wouldn't it make sense to implement a selector 
interface on top of the golang AST, something like CSS or JQ selectors but 
targeted at the go language constructs? I've stumbled across Guru but it 
does seem to target a slightly different use case.

Is anybody aware of such a selector lib/module or does the idea even sound 
interesting?

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/2366cfa7-3884-499f-b97f-97c6e6c033f7n%40googlegroups.com.

[go-nuts] Re: CSS-like selectors for Go AST?

[cpu...@gmail.com]

Hi Max,

Great answer, thank you! Exactly what I was looking for in terms of a fluid 
api, no need for parsing the selectors.

The API is not quite suitable for public consumption. I feel this could be 
a great success if extracted into its own module.
Could you kindly clarify what the meaning of the int parameters is, i.e. is 
there a general rule or does it depend on the function?

I‘ll play a bit with it and will comment on GH if ok.

Much appreciated,
Andi

On Wednesday, October 14, 2020 at 6:09:08 PM UTC+2 Max wrote:

> I can only agree, traversing or navigating Go AST is cumbersome for at 
> least two reasons:
> 1. each type has its own fields - no uniform API is available
> 2. you often need type assertions on fields because they have interface 
> type instead of concrete type
>
> I developed a wrapper around them to mitigate these problems for my Go 
> interpreter https://github.com/cosmos72/gomacro
> If you are interested, it is the package 
> https://github.com/cosmos72/gomacro/tree/master/ast2
>
> You may find it helps by providing an uniform API and removing the need 
> for type assertions, but it still requires compile-time code,
> not CSS-style strings that can be created at runtime.
>
> A quick example:  this uses plain go/ast
> ```
> package main
> import (
> "fmt"
> "go/ast"
> "go/parser"
> )
> func main() {
> x, _ := parser.ParseExpr("foo[1 + 2 * 3]")
> // we want to extract the "3"
> var three string = 
> x.(*ast.IndexExpr).Index.(*ast.BinaryExpr).Y.(*ast.BinaryExpr).Y.(*ast.BasicLit).Value
> fmt.Printf("%s\n", three) // prints 3
> }
> ```
> while this is the equivalent using github.com/cosmos72/gomacro/ast2
> ```
> package main
> import (
> "fmt"
> "go/ast"
> "go/parser"
> "github.com/cosmos72/gomacro/ast2"
> )
> func main() {
> x, _ := parser.ParseExpr("foo[1 + 2 * 3]")
> y := ast2.AnyToAst(x, nil) // wrap the existing AST. does not allocate 
> memory.
> 
> ythree := y.Get(1).Get(1).Get(1) // extract the "3" as ast2.Node
>
> // now unwrap it, getting the *ast.BasicLit and the Value inside it
> var three string = ast2.ToBasicLit(ythree).Value
> fmt.Printf("%s\n", three) // prints 3
> }
> ```
>
> On Tuesday, October 13, 2020 at 9:37:21 AM UTC+2 cpu...@gmail.com wrote:
>
>> Good morning.
>>
>> I've recently found myself writing a code generator for dynamic interface 
>> composition at runtime. It became ugly and I had to pass in quite a number 
>> of parameters that should have been available from reading the source code.
>>
>> In a second attempt I've reimplemented the generator using stringer-like 
>> AST handling. It worked well but was cumbersome to code.
>>
>> Now an idea surfaced: wouldn't it make sense to implement a selector 
>> interface on top of the golang AST, something like CSS or JQ selectors but 
>> targeted at the go language constructs? I've stumbled across Guru but it 
>> does seem to target a slightly different use case.
>>
>> Is anybody aware of such a selector lib/module or does the idea even 
>> sound interesting?
>>
>> 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/d7eca821-f060-49de-b9cd-67d1b95d2b70n%40googlegroups.com.

[go-nuts] Why do type aliases change behaviour (i.e. json.Unmarshal)?

[cpu...@gmail.com]

I've just tried doing something like this in my code:

// Token is an OAuth2 token which includes decoding the expires_in attribute
type Token struct {
oauth2.Token
ExpiresIn int `json:"expires_in"` // expiration time in seconds
}

func (t *Token) UnmarshalJSON(data []byte) error {
...
}

type WrappedToken Token

Only to find out, that unmarshaling a WrappedToken does not call 
Token.UnmarshalJSON which came as a bit of surprise.

I can only guess it's due to how JSON unmarshaling works, but is this the 
intended behaviour?

Kind regards,
Andreas

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

Re: [go-nuts] Why do type aliases change behaviour (i.e. json.Unmarshal)?

[cpu...@gmail.com]

Thank you @Michel. Disturbing that I keep making the same mistake again...

On Monday, March 15, 2021 at 2:05:53 PM UTC+1 mlevi...@gmail.com wrote:

> This is because per the Go spec: 
> https://golang.org/ref/spec#Type_declarations
> You're not creating an alias to Token, but defining a new type from it. If 
> what you are looking for is an alias (meaning to have the "WrappedToken" 
> identifier refer to the exact same type as Token), you need to do:
>
> type WrappedToken = Token
>
> Then all method calls on WrappedToken will be method calls on Token (since 
> both identifier denote the same type).
>
> But maybe that is not what you are looking for, if that's the case, there 
> are other ways around the problem, like type embedding and such.
> Hope this helps,
>
> Le lun. 15 mars 2021 à 13:49, cpu...@gmail.com  a 
> écrit :
>
>> I've just tried doing something like this in my code:
>>
>> // Token is an OAuth2 token which includes decoding the expires_in 
>> attribute
>> type Token struct {
>> oauth2.Token
>> ExpiresIn int `json:"expires_in"` // expiration time in seconds
>> }
>>
>> func (t *Token) UnmarshalJSON(data []byte) error {
>> ...
>> }
>>
>> type WrappedToken Token
>>
>> Only to find out, that unmarshaling a WrappedToken does not call 
>> Token.UnmarshalJSON which came as a bit of surprise.
>>
>> I can only guess it's due to how JSON unmarshaling works, but is this the 
>> intended behaviour?
>>
>> Kind regards,
>> Andreas
>>
>> -- 
>> You received this message because you are subscribed 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/0ceb1917-af61-4259-8695-55eeb0bd6bffn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/0ceb1917-af61-4259-8695-55eeb0bd6bffn%40googlegroups.com?utm_medium=email&utm_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/77f8d500-4f9d-4558-8be5-658230cbb18an%40googlegroups.com.

[go-nuts] Fixing deprecated: golang.org/x/oauth2: Transport.CancelRequest no longer does anything; use contexts

[cpu...@gmail.com]

Hi all,

I've recently learned about oauth2 and started to convert some of my 
"manual" code using net/http to use an  underlying oauth2.Transport for 
executing authenticated requests and token refresh.

As a result, my application now sometimes shows 

deprecated: golang.org/x/oauth2: Transport.CancelRequest no longer does 
anything; use contexts

Of course, I'm nowhere calling that method. Digging into the default HTTP 
Client 
(https://github.com/golang/go/blob/a937729c2c2f6950a32bc5cd0f5b88700882f078/src/net/http/client.go)
 
reads:

// For compatibility, the Client will also use the deprecated
// CancelRequest method on Transport if found. New
// RoundTripper implementations should use the Request's Context
// for cancellation instead of implementing CancelRequest.
Timeout time.Duration

I would read this as: if you have an http.Client with an underlying 
oauth2.Transport and the request times out, the oauth2.Transport's 
CancelRequest method will *always* be called and hence show the undesired 
warning.

Is that correct?

Thanks,
Andreas

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0dff84c5-9b62-4d55-8228-28b0367eab72n%40googlegroups.com.

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

[cpu...@gmail.com]

On Thursday, March 18, 2021 at 1:53:30 PM UTC+1 ren...@ix.netcom.com wrote:

> One other point on this. Generics will be trivial for 95% of the people - 
> they will only need to be able to read and write the instantiation 
> statements of type safe collections. 
>
> Most developers don’t write the generic implementations - these are 
> provided by library authors. 
>

That is an unsupported claim. I've waited for Go to have generics for the 
simple case of having compile time type safety of registry patterns instead 
of copying my code x times for resorting to go:generate. It just makes life 
much easier.

As I’ve said before, I would of taken a more go-like approach - generics 
> seem too technical for most go developers - but in the end they will be a 
> net benefit. 
>

The community has tuned and chosen the approach. The discussion of type 
params imho proves that "no good" designs are iterated until they are 
acceptable to a majority. You can support these discussions.

Cheers

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/56ebe8cc-ab0d-40d4-b478-a7bc92bc321an%40googlegroups.com.

[go-nuts] Re: Fixing deprecated: golang.org/x/oauth2: Transport.CancelRequest no longer does anything; use contexts

[cpu...@gmail.com]

Opened https://github.com/golang/oauth2/issues/487 to propose removing the 
`CancelRequest` method.

Cheers,
Andreas

On Friday, March 19, 2021 at 5:44:21 PM UTC+1 cpu...@gmail.com wrote:

> Hi all,
>
> I've recently learned about oauth2 and started to convert some of my 
> "manual" code using net/http to use an  underlying oauth2.Transport for 
> executing authenticated requests and token refresh.
>
> As a result, my application now sometimes shows 
>
> deprecated: golang.org/x/oauth2: Transport.CancelRequest no longer 
> does anything; use contexts
>
> Of course, I'm nowhere calling that method. Digging into the default HTTP 
> Client (
> https://github.com/golang/go/blob/a937729c2c2f6950a32bc5cd0f5b88700882f078/src/net/http/client.go)
>  
> reads:
>
> // For compatibility, the Client will also use the deprecated
> // CancelRequest method on Transport if found. New
> // RoundTripper implementations should use the Request's Context
> // for cancellation instead of implementing CancelRequest.
> Timeout time.Duration
>
> I would read this as: if you have an http.Client with an underlying 
> oauth2.Transport and the request times out, the oauth2.Transport's 
> CancelRequest method will *always* be called and hence show the undesired 
> warning.
>
> Is that correct?
>
> Thanks,
> Andreas
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/76840e3d-f555-4be1-baa7-78aa2f98d1d8n%40googlegroups.com.

[go-nuts] How to wait for HTTP server to start?

[cpu...@gmail.com]

The typical Go tutorials pattern for starting a server is something like 

log.Fatal(http.ListenAndServe(":8080"))

But what if the application needs to do other things after the server is 
started? It seems there is virtually no method to wait for the server 
actually start listening to requests?

I'm probably missing something and would appreciate a hint.

Thanks,
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/a40222e3-e4b3-4996-8232-045fcff43b77n%40googlegroups.com.

Re: [go-nuts] How to wait for HTTP server to start?

[cpu...@gmail.com]

On Monday, March 29, 2021 at 9:05:50 PM UTC+2 rog wrote:

> I often call net.Listen directly before calling Serve in a goroutine. That 
> way you can connect to the server's socket immediately even though the 
> server might take a while to get around to serving the request.
>
 
It seems this would work as long as the server is not using HTTPS and needs 
to perform a handshake first?

Look at how net/http/httptest does it.
>

I wasn't sure if you're referring to goServe 
https://github.com/golang/go/blob/master/src/net/http/httptest/server.go#L304 
which is called from Start()? This seems to return only after the server is 
stopped.
I've found the idea interesting though. Using a WaitGroup you could at 
least ensure that the gofunc containing the call to Serve() has at least be 
started. That still doesn't seem to be sufficient though:

ln, err := net.Listen("tcp", ":"+port)
if err != nil {
log.Fatal(err)
}

var wg sync.WaitGroup
wg.Add(1)

go func() {
server := &http.Server{Addr: ":" + port, Handler: handler}
wg.Done()
log.Fatal(server.Serve(ln))
}()

wg.Wait()

Cheers,
Andi
 

>
> On Sat, 27 Mar 2021, 14:13 cpu...@gmail.com,  wrote:
>
>> The typical Go tutorials pattern for starting a server is something like 
>>
>> log.Fatal(http.ListenAndServe(":8080"))
>>
>> But what if the application needs to do other things after the server is 
>> started? It seems there is virtually no method to wait for the server 
>> actually start listening to requests?
>>
>> I'm probably missing something and would appreciate a hint.
>>
>> Thanks,
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/a40222e3-e4b3-4996-8232-045fcff43b77n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/a40222e3-e4b3-4996-8232-045fcff43b77n%40googlegroups.com?utm_medium=email&utm_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/a52551ab-b5bb-4696-b683-6d9c03093c88n%40googlegroups.com.

[go-nuts] Can I import a package from a git submodule?

[cpu...@gmail.com]

Consider this layout:


   - Repo A contains module foo
   - Repo B contains module bar (of course ;)
   - Repo B is added as submodule to repo A at /baz


I was expecting that I can 

import "foo/baz/bar"

in repo A, but that leads to error ("no required module provides 
package...").

Shouldn't this work as the import path is a perfectly valid import path 
inside module foo?

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/1f2bab6e-47cf-4f80-9a66-3a8bad2869ban%40googlegroups.com.

[go-nuts] Autocert failure with HTTP handler

[cpu...@gmail.com]

Hello, 

I have a very stupid problem with autocert. The below code works:

log.Println("sslHosts:", sslHosts)
log.Println("sslCertDir:", sslCertDir)

certManager := autocert.Manager{
Prompt: autocert.AcceptTOS,
HostPolicy: autocert.HostWhitelist(strings.Split(sslHosts, " ")...),
Cache: autocert.DirCache(sslCertDir),
}

go func() {
log.Fatal(http.ListenAndServe(":http", certManager.HTTPHandler(nil)))
}()
// go log.Fatal(http.ListenAndServe(":http", certManager.HTTPHandler(nil)))

s.Addr = ":https"
s.TLSConfig = certManager.TLSConfig()

log.Fatal(s.ListenAndServeTLS("", ""))

Once I remove the go func() and uncomment the // go log line, the server no 
longer serves HTTPS requests while HTTP continues to work. 

I'm totally stumped- the two go funcs should imho be equivalent? Any 
insight what's wrong here would be highly appreciated. 

I'm using go 1.16.3-arm64 on Darwin, cross-compiled to amd64.

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/3b9683bc-3bd6-4a43-b82e-0f4834419a32n%40googlegroups.com.

[go-nuts] Re: Autocert failure with HTTP handler

[cpu...@gmail.com]

That makes perfect sense as the simple reproducer 
shows: https://play.golang.org/p/vSEBtdV2CzR

Only in this case I didn't see it as there were more go routines alive.

Much appreciated, thank you!

On Monday, April 19, 2021 at 11:29:31 PM UTC+2 Brian Candler wrote:

> As far as I understand it: "go foo(bar, baz)" evaluates all the arguments 
> first, *then* starts a goroutine with function foo(val1, val2)
>
> Since http.ListenAndServe() never returns [unless it fails to start], it 
> never gets as far as starting a goroutine for log.Fatal, and therefore 
> cannot continue to the rest of the 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/a6a54717-8900-429a-953b-f67cde373fafn%40googlegroups.com.

[go-nuts] Suggestion to extend x/OAuth2 API

[cpu...@gmail.com]

After working with a few more-or-less OAuth2 APIs lately, I would like to 
propose slightly extending the API footprint of the oauth2 library. 

By doing so I expect that the amount of userland/provider-specific code can 
be reduced- both inside oauth2 and outside in realworld applications. Some 
of the ideas have been proposed in 
https://github.com/golang/oauth2/issues/483 and 
https://github.com/golang/oauth2/issues/484.

Most notably, it would be nice if OAuth2 could cater for the following 
situations:
- OAuth2 tokens with `expires_in` field (already handled by internal and in 
some of the OAuth2 providers)
- Add a `TokenRefresher` interface (currently implemented by 
`tokenRefresher`) that can be passed to a `ReuseTokenSource` for performing 
the actual token refresh to allow more flexible refresh scenarios.

With these two changes, x/oauth2 could be more widely used without need for 
reimplementation of the above parts plus might deduplicate parts of the 
implemented providers.

Hope the above points make sense, happy to take feedback.

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/923aed15-f01e-4d1a-92f9-23f31d4d5255n%40googlegroups.com.

[go-nuts] Re: Suggestion to extend x/OAuth2 API

[cpu...@gmail.com]

There is some support for a configurable token source 
in https://github.com/golang/oauth2/pull/448#issuecomment-835811792, no 
feedback otherwise.

Cheers,
Andi

On Thursday, April 22, 2021 at 6:10:38 PM UTC+2 cpu...@gmail.com wrote:

> After working with a few more-or-less OAuth2 APIs lately, I would like to 
> propose slightly extending the API footprint of the oauth2 library. 
>
> By doing so I expect that the amount of userland/provider-specific code 
> can be reduced- both inside oauth2 and outside in realworld applications. 
> Some of the ideas have been proposed in 
> https://github.com/golang/oauth2/issues/483 and 
> https://github.com/golang/oauth2/issues/484.
>
> Most notably, it would be nice if OAuth2 could cater for the following 
> situations:
> - OAuth2 tokens with `expires_in` field (already handled by internal and 
> in some of the OAuth2 providers)
> - Add a `TokenRefresher` interface (currently implemented by 
> `tokenRefresher`) that can be passed to a `ReuseTokenSource` for performing 
> the actual token refresh to allow more flexible refresh scenarios.
>
> With these two changes, x/oauth2 could be more widely used without need 
> for reimplementation of the above parts plus might deduplicate parts of the 
> implemented providers.
>
> Hope the above points make sense, happy to take feedback.
>
> 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/d1cfce97-7b7e-4d8d-8b84-e28e221d91f2n%40googlegroups.com.

[go-nuts] How can I check error types of gRPC calls?

[cpu...@gmail.com]

In my local code, I'm using things like

if errors.Is(err, api.ErrMustRetry) { ... }

How would I achieve the same on errors returned by the gRCP interface? I've 
noticed these are wrapped: 

rpc error: code = Unknown desc = must retry rpc error: code = Unknown desc 
= must retry

I assume the errors package won't work here as type information is not 
carried across gRPC: What is the best practice here: unwrap the root error 
from the RPC result (how) and perform string comparison?

Thanks,
Andreas

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c3053cb0-d739-496d-a804-7f533ba7a6cbn%40googlegroups.com.

Re: [go-nuts] How can I check error types of gRPC calls?

[cpu...@gmail.com]

Thank you for the pointer. After looking at the API, I'm still confused how 
to use it. I can status.Convert(err) to get a status object but couldn't 
really figure how how to use that to extract the actual underlying base 
error?
On Saturday, May 15, 2021 at 2:12:28 PM UTC+2 kortschak wrote:

> On Sat, 2021-05-15 at 04:47 -0700, cpu...@gmail.com wrote:
> > In my local code, I'm using things like
> >
> > if errors.Is(err, api.ErrMustRetry) { ... }
> >
> > How would I achieve the same on errors returned by the gRCP
> > interface? I've noticed these are wrapped:
> >
> > rpc error: code = Unknown desc = must retry rpc error: code = Unknown
> > desc = must retry
> >
> > I assume the errors package won't work here as type information is
> > not carried across gRPC: What is the best practice here: unwrap the
> > root error from the RPC result (how) and perform string comparison?
> >
>
> There is the status package which provides tools for examining the gRPC
> errors, https://pkg.go.dev/google.golang.org/grpc/status.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8ecd4024-a846-4657-8e61-15c16289ccd2n%40googlegroups.com.

[go-nuts] A little love for x/oauth2

[cpu...@gmail.com]

I've recently worked a bit with oauth2 and noticed that issue tracker and 
PRs could use a little love. Quite a number of PRs have gone through Gerrit 
review without merging and the issues contain some imho valid points.

Is there a policy for maintaining x/oauth2 or putting it into slower 
maintenance-only mode?

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/d026d6f0-d493-400e-8c6f-c254d9a8b703n%40googlegroups.com.

[go-nuts] How to use errors.As with sentinel errors?

[cpu...@gmail.com]

Consider this example: https://play.golang.org/p/16cU0kc8Lku, basically

var Err = errors.New("sentinel")
err := errors.New("foo")
if errors.As(err, &Err) {
  fmt.Println("why?")
}

I'm wondering why this matches the sentinel error, or rather how to 
properly use sentinel errors. errors.As says "An error matches target if 
the error's concrete value is assignable to the value pointed to by 
target". This seems to be the case here (both are of type error).

However, if thats the case, how should I construct a sentinel error that 
would be usable with errors.As? I don't want to rely on errors.Is as errors 
could be wrapped. So to "break" the assignability- would that mean that I'd 
need to define sentinel errors as e.g. struct types?

Seem's I'm still lacking the level of understanding for go errors that I'd 
aspire to :/

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/4d8969b4-dd5a-4834-893b-3e01174570bfn%40googlegroups.com.

[go-nuts] Re: How to use errors.As with sentinel errors?

[cpu...@gmail.com]

Ah, think I found it: https://blog.golang.org/go1.13-errors says:

In the simplest case, the errors.Is function behaves like a comparison to a 
sentinel error, and the errors.Asfunction behaves like a type assertion. 
When operating on wrapped errors, however, these functions consider all the 
errors in a chain. 

So I should just use errors.Is here... Sorry for the confusion!
On Monday, August 2, 2021 at 10:02:11 AM UTC+2 cpu...@gmail.com wrote:

> Consider this example: https://play.golang.org/p/16cU0kc8Lku, basically
>
> var Err = errors.New("sentinel")
> err := errors.New("foo")
> if errors.As(err, &Err) {
>   fmt.Println("why?")
> }
>
> I'm wondering why this matches the sentinel error, or rather how to 
> properly use sentinel errors. errors.As says "An error matches target if 
> the error's concrete value is assignable to the value pointed to by 
> target". This seems to be the case here (both are of type error).
>
> However, if thats the case, how should I construct a sentinel error that 
> would be usable with errors.As? I don't want to rely on errors.Is as errors 
> could be wrapped. So to "break" the assignability- would that mean that I'd 
> need to define sentinel errors as e.g. struct types?
>
> Seem's I'm still lacking the level of understanding for go errors that I'd 
> aspire to :/
>
> 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/7a495842-a022-4c41-92aa-39e8dff00f97n%40googlegroups.com.

[go-nuts] How to diagnose a stuck program

[cpu...@gmail.com]

Developing https://github.com/evcc-io/evcc I've recently had a bug report 
of unresponsive application. Logfile shows, that the program still has 
alive go routines but the main loop doesn't show up in the logs any more, 
to it seems stuck.

This may be more a Unix than a Go question: can I connect to the running 
program and figure out where it's stuck. Any answers or pointers to 
external ressources appreciated.

Thanks,
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/b75cb767-e911-4dcc-a215-e4a1024ab270n%40googlegroups.com.

[go-nuts] gob: decoding into local type []float64, received remote type []float

[cpu...@gmail.com]

I'm trying to transfer arbitrary structs over gRPC. To achieve this I've 
trying to use gob for encoding the interface{} part of the structs. The 
code looks somewhat like https://go.dev/play/p/4Q5CQE4Wcy2 but not entirely.

Two things strike me strange:
- I receive "gob: decoding into local type []float64, received remote type 
[]float" during Decode when the interface is a []float64
- I need to use &res.Val (which is an interface) or it will stay nil. Using 
res.Val (which imho works with JSON when the target is an interface) does 
always lead to nil result.

I would appreciate any hint how to gRPC or gob.Encode interfaces properly.

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/b25cd32b-f789-419e-93a7-d4e149a70db1n%40googlegroups.com.

[go-nuts] Re: gob: decoding into local type []float64, received remote type []float

[cpu...@gmail.com]

Turns out that the decoding problem only exist when I reuse the encoder:

b := new(bytes.Buffer)
enc := gob.NewEncoder(b)

for param := range in {
b.Reset()
if err := enc.Encode(¶m.Val); err != nil {
panic(err)
}

// send encoded data
}

When I create a new encode inside the loop things are fine. I couldn't find 
anything regarding enc that should prevent reusing it?

Cheers,
Andi
On Sunday, November 28, 2021 at 9:10:37 PM UTC+1 cpu...@gmail.com wrote:

> I'm trying to transfer arbitrary structs over gRPC. To achieve this I've 
> trying to use gob for encoding the interface{} part of the structs. The 
> code looks somewhat like https://go.dev/play/p/4Q5CQE4Wcy2 but not 
> entirely.
>
> Two things strike me strange:
> - I receive "gob: decoding into local type []float64, received remote type 
> []float" during Decode when the interface is a []float64
> - I need to use &res.Val (which is an interface) or it will stay nil. 
> Using res.Val (which imho works with JSON when the target is an interface) 
> does always lead to nil result.
>
> I would appreciate any hint how to gRPC or gob.Encode interfaces properly.
>
> 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/589e4ba5-afe4-4cee-9398-326478171492n%40googlegroups.com.

[go-nuts] What are best practices for synchronizing data access in web applications?

[cpu...@gmail.com]

I've developed a semi-complex server application (https://evcc.io) with web 
ui. Since web requests are async per nature and I wan't to service them 
quickly, mutexes are used. I'm now at the point where I realise that 
sprinkling (un)locks over the code quickly leads to deadlocks and 
unforeseeable complexity.

What are good patterns to cope with that? Some I could imagine are:
- granular locks, maybe plus rigorous use of getters/setters
- some sort of synchronised data container (also eliminated 
unwanted/undetected access)
- clear naming scheme/separation of concerns

Are there any best practices/ talks/ presentations I could refer to?

Thanks,
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/3b6a321c-cbe3-47ae-9afa-17e6cbf6b0can%40googlegroups.com.

[go-nuts] x/exp/slices: add Map/Extract function

[cpu...@gmail.com]

Playing with 1.18 I've noticed that I can immediately replace pretty much 
all uses of https://github.com/thoas/go-funk with the new slices package. 

One common use case that I happen to have in the codebase quite a lot is 
extracting data from a slice of objects:

funk.Map(chargers, func(c easee.Charger) string { return c.ID })

I feel it would be nice to add something like that as part of slices:

func Map[From, To any](s []From, f func(From) To) []To {
res := make([]To, len(s))
for i, v := range s {
res[i] = f(v)
}
return res
}

Has this already been discussed?

Thanks,
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/73289ac6-788e-42d4-85e9-00486a970c21n%40googlegroups.com.

Re: [go-nuts] encoding/asn1 overly strict?

[cpu...@gmail.com]

Sorry to revive this ancient discussion. 

We've come 
across 
https://forum.golangbridge.org/t/x509-certificate-parse-error-with-iot-device/27622/2
 
where an IOT device from a large vendor uses BER for it's TLS certificate. 
It's unlikely, that the vendor will fix the certificate any time soon. 
We've not found an approach for communicating with the device sofar unless 
using patched Go stdlib.

Are there any options we could use to accept a BER-encoded ASN.1 
certificate for TLS connections?

Thanks!

On Thursday, July 2, 2015 at 1:28:26 AM UTC+2 matt@gmail.com wrote:

> Just to be clear, SNMP (and LDAP) uses BER, not DER. It's not sloppy or 
> non-compliant that the data you're getting isn't DER. DER is used for more 
> specific purposes than BER. I would support a more extensive version of the 
> asn1 package being created; I might help out with the development. 
> Eventually the new version could be included in the standard library if the 
> language maintainers find it compelling enough.
>
> On Wed, Jul 1, 2015 at 9:43 AM 'Paul Borman' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> It seems there is a strong feeling the ability to enforce DER is 
>> required.  Fair enough.  That does not mean it cannot accept BER, only that 
>> the current API will only accept DER.  The package benefit from having a 
>> mechanism to select between BER and strict DER enforcement.  The package is 
>> not named der, after all.  The documentation, at a minimum, could probably 
>> be improved.
>>
>> Craig, if you want this in, maybe file an issue to flesh out the asn1 
>> package.
>>
>> Hopefully fleshing out this package, while retaining all existing 
>> semantics, would be acceptable.   My personal feeling is that general use 
>> packages should be as complete as reasonably possible, not just sufficient 
>> for the initial motivation/use case.  That view comes from the experience 
>> of having been a an OS developer for 25 years (BSDi and Cray).
>>
>> -Paul
>>
>> *expedient* |ikˈspēdēənt|
>> *adjective*
>> Doing something to save time today that you will regret tomorrow.
>>
>> On Tue, Jun 30, 2015 at 1:57 PM, Craig Peterson  
>> wrote:
>>
>>> I can appreciate that reasoning, even if the outcome is not sufficient 
>>> for my needs. None of the packages I have found for ber are maintained or 
>>> of very high quality. I will likely fork encoding/asn1 and apply the 
>>> changes I need.
>>>
>>> On Tuesday, June 30, 2015 at 2:54:33 PM UTC-6, Matt Harden wrote:

 "Package asn1 implements parsing of DER-encoded ASN.1 data structures, 
 as defined in ITU-T Rec X.690."

 It's only present in the standard library to support TLS. In the case 
 of TLS it is often *less secure* to be liberal in what you receive. DER is 
 designed have one and only one way to represent data. Validation of 
 conformance to DER is important while parsing this data.

 The package is not intended for SNMP or LDAP or other purposes. Other 
 packages exist outside the standard library to parse BER.

 On Tue, Jun 30, 2015 at 2:01 PM Craig Peterson  
 wrote:

> I agree completely. I made a CR to modify the package, but it wasn't 
> received well: https://go-review.googlesource.com/#/c/11734/
>
>
> On Tuesday, June 30, 2015 at 11:34:49 AM UTC-6, Paul Borman wrote:
>
>> It is probably better, if you have only one, to accept BER and 
>> produce DER.  That is pretty much the standard networking mantra.  Be 
>> liberal in what you receive and conservative in what you send.
>>
>>-Paul
>>
> On Tue, Jun 30, 2015 at 10:17 AM, Matt Harden  
>> wrote:
>>
> If the data you're decoding is not canonical, then it's not DER. It's 
>>> probably BER. DER is a strict subset of BER, and by definition there is 
>>> only one way to represent a particular value in DER, which is the whole 
>>> point. Unfortunately the asn1 package does not include a BER decoder.
>>>
>>> See http://go-search.org/search?q=ber
>>>
>> On Tue, Jun 30, 2015 at 11:25 AM  wrote:
>>>
>> I am having an issue where a network device I am communicating with 
 is returning asn1 that the encoding/asn1 package refuses to parse.

 The byte stream I am reading is 0x30(sequence) 82(2 bytes for 
 length to follow) 00 12 (length of 18). The asn1 package has a check 
 at 
 https://github.com/golang/go/blob/master/src/encoding/asn1/asn1.go#L472
  
 that does not like the zero byte at the beginning of the length, 
 citing the 
 DER spec as the reason why.

 Yes, the length here could be expressed as two, or even one byte, 
 but it seems there are multiple implementations in the wild that do 
 not 
 honor the spec in this regard. It would make sense to me to relax the 
 restriction a bit in encoding/asn1 and only ch

Re: [go-nuts] encoding/asn1 overly strict?

[cpu...@gmail.com]

On Wednesday, June 8, 2022 at 5:53:50 PM UTC+2 Brian Candler wrote:

> On Wednesday, 8 June 2022 at 10:09:26 UTC+1 andig wrote:
>
>> We've not found an approach for communicating with the device sofar 
>> unless using patched Go stdlib.
>>
>
> Connect via a proxy like stunnel?
>
> Out of interest, does raw "openssl s_client" allow communication with the 
> device?
>

We receive an alert 40 (Handshake failure ) when using openssl. So the cert 
is definitively faulty in some way. 

 :~/wallbox/hack$ openssl s_client  -connect 192.168.1.180:4712 

CONNECTED(0005)

depth=0 CN = EEBUS, O = EVBox Intelligence, C = NL

verify error:num=18:self signed certificate

verify return:1

depth=0 CN = EEBUS, O = EVBox Intelligence, C = NL

verify return:1

140477570593216:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert 
handshake failure:../ssl/record/rec_layer_s3.c:1528:SSL alert number 40

---

Certificate chain

0 s:CN = EEBUS, O = EVBox Intelligence, C = NL

   i:CN = EEBUS, O = EVBox Intelligence, C = NL

---

Server certificate

-BEGIN CERTIFICATE-
MIIBszCCAVmgAwIBAgIBATAKBggqhkjOPQQDAjA6MQ4wDAYDVQQDDAVFRUJVUzEb 

Seems that in this case- if we regard openssl as "the standard" it's 
obsolete to talk about Go.


> It would seem reasonable to me for InsecureSkipVerify to skip certificates 
> without parsing them at all.  It is, after all, insecure by definition.
>

It doesn't do that as it checks for supported ciphers afterwards, so it 
needs to decode the cert first.
 
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/e7270ed8-35bd-428f-8ec8-69e50d48b0b7n%40googlegroups.com.

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

[cpu...@gmail.com]

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.

[go-nuts] Patching Go sources - which files end up in the build?

[cpu...@gmail.com]

For various reasons we need to patch cryptobytes for our build 
(https://github.com/evcc-io/eebus/issues/1#issuecomment-1146843187). 

We've tried to do this in a consistent way for local, Docker and Github CI 
build by vendoring our modules (go mod vendor) and patching the vendored 
copy. Test confirms the vendored copy is successfully patched 
(https://github.com/evcc-io/evcc/blob/master/main.go#L37).

However, and that part is harder to explain, our application- when 
receiving TLS connections- still seems to act as if the patch is not in 
place. Since cryptobytes is also part of GOROOT I'm wondering is there is 
any chance of the original file ending up in our build, too?

What is the role of GOROOT for the final binary and which files (vendored 
vs. mod cache vs. GOROOT) really end up the build in the end?

Much appreciated,
Andreas (andig)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8ecc71ca-4d44-4be4-a4ad-401d4687e40cn%40googlegroups.com.

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

[cpu...@gmail.com]

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

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

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

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


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8a2e6351-b88a-46ff-917b-af9110aa8aaan%40googlegroups.com.

[go-nuts] Drain channel on demand without busy looping?

[cpu...@gmail.com]

I have the requirement of being able to drain a channel, i.e. make sure 
that downstream processes all data currently being sent. One possible 
pattern is something like

for{
select{
case <-q.data:
default:
}
}

where the default branch could indicate that channel has been drained. My 
concern is, that this would create a busy loop on the default branch even 
when not trying to drain the channel.

I could use an atomic for checking if work should be done in default (i.e. 
signal channel has been drained).

Would that still busy-loop? Are there better patterns?

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/4887e28d-bcfb-4f49-9450-00e56e00be55n%40googlegroups.com.

[go-nuts] Using struct{} for context keys

[cpu...@gmail.com]

I've recently stumbled across code like this 
https://go.dev/play/p/u3UER2ywRlr:

type clientContextKey struct{}

ctx := context.Background()
ctx = context.WithValue(ctx, clientContextKey{}, "foo")
_, ok := ctx.Value(clientContextKey{}).(string)

Naively, I had expected this to fail since I assumed that 
clientContextKey{} would create a new variable instance every time it was 
used and hence the keys would not match.

Why does this use of instantiating the struct type work here?

Thanks,
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/55783f87-bad8-4ca4-9c4a-d8686ae156abn%40googlegroups.com.

[go-nuts] Using log/slog with log.Logger format?

[cpu...@gmail.com]

The log/slog logger uses the log.Logger format by default. Implementation 
is internal.

In a gradual switch to slog I'd like to keep that format for time being but 
customize other handler options- hence need to create a new Logger. Is 
there a good way to do that without reimplementing the entire internal slog 
logic around commonHandler etc?

Cheers,
Andreas

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/798dc77c-a307-40cb-b1e8-1e72995fd331n%40googlegroups.com.

[go-nuts] Re: Using log/slog with log.Logger format?

[cpu...@gmail.com]

Seems it's not possible to create a logger using the log.Logger format in a 
straight-forward way?

On Thursday, July 20, 2023 at 3:48:49 PM UTC+2 cpu...@gmail.com wrote:

> The log/slog logger uses the log.Logger format by default. Implementation 
> is internal.
>
> In a gradual switch to slog I'd like to keep that format for time being 
> but customize other handler options- hence need to create a new Logger. Is 
> there a good way to do that without reimplementing the entire internal slog 
> logic around commonHandler etc?
>
> Cheers,
> Andreas
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0bca800d-f49a-4feb-9ce8-235ec3b03580n%40googlegroups.com.

[go-nuts] Go 1.22 binary size improvements?

[cpu...@gmail.com]

I was surprised to see my application (MacOS binary) go from 93MB to 81MB 
(no PGO). Release notes don't mention this.

Has anyone made similar experience or knows why that is?

Thanks,
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/d9ba2568-90d7-4a0f-8b25-83a3f01ad662n%40googlegroups.com.

[go-nuts] Re: Go 1.22 binary size improvements?

[cpu...@gmail.com]

It's really surprising (positively). Compiling with -ldflags='-s -w' if 
anyone wants to try this.

On Friday, February 9, 2024 at 1:23:20 PM UTC+1 qiulaidongfeng wrote:

> Quick search to find go1.22 as follows  CL  like  
> https://go-review.googlesource.com/c/go/+/521615   reduces binary size. 
> However, from 93MB to 81MB, I think it is most likely the result of the 
> joint efforts of many CLs.
>
> On Friday, February 9, 2024 at 7:46:48 PM UTC+8 cpu...@gmail.com wrote:
>
>> I was surprised to see my application (MacOS binary) go from 93MB to 81MB 
>> (no PGO). Release notes don't mention this.
>>
>> Has anyone made similar experience or knows why that is?
>>
>> Thanks,
>> 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/c93a73d1-ea18-4d12-9127-0787ffb5f51cn%40googlegroups.com.

[go-nuts] Re: Go 1.22 binary size improvements?

[cpu...@gmail.com]

Just gave it another try cross-compiling to Arm on Linux. This time binary 
size stays the same. Sorry if my excitement was too premature.

On Friday, February 9, 2024 at 2:11:25 PM UTC+1 cpu...@gmail.com wrote:

> It's really surprising (positively). Compiling with -ldflags='-s -w' if 
> anyone wants to try this.
>
> On Friday, February 9, 2024 at 1:23:20 PM UTC+1 qiulaidongfeng wrote:
>
>> Quick search to find go1.22 as follows  CL  like  
>> https://go-review.googlesource.com/c/go/+/521615   reduces binary size. 
>> However, from 93MB to 81MB, I think it is most likely the result of the 
>> joint efforts of many CLs.
>>
>> On Friday, February 9, 2024 at 7:46:48 PM UTC+8 cpu...@gmail.com wrote:
>>
>>> I was surprised to see my application (MacOS binary) go from 93MB to 
>>> 81MB (no PGO). Release notes don't mention this.
>>>
>>> Has anyone made similar experience or knows why that is?
>>>
>>> Thanks,
>>> 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/74abf623-f1cc-4835-9893-8bc91d3e2afbn%40googlegroups.com.

[go-nuts] Re: Go 1.22 binary size improvements?

[cpu...@gmail.com]

Yes, CGO is disabled. ldd doesn't seem to exist on MacOS:

make build && ls -la ./evcc && otool -L ./evcc

1.21.7

CGO_ENABLED=0 go build -v -tags=release -trimpath -ldflags='-X 
github.com/evcc-io/evcc/server.Version=0.124.1 -X 
github.com/evcc-io/evcc/server.Commit=596071b42 -s -w'
-rwxr-xr-x  1 andig  staff  *93824418*  9 Feb 14:38 ./evcc
./evcc:
/usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current 
version 0.0.0)
/usr/lib/libresolv.9.dylib (compatibility version 0.0.0, current 
version 0.0.0)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security 
(compatibility version 0.0.0, current version 0.0.0)

1.22.0

CGO_ENABLED=0 go build -v -tags=release -trimpath -ldflags='-X 
github.com/evcc-io/evcc/server.Version=0.124.1 -X 
github.com/evcc-io/evcc/server.Commit=596071b42 -s -w'
-rwxr-xr-x  1 andig  staff  *81119026*  9 Feb 14:37 ./evcc
./evcc:
/usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current 
version 0.0.0)
/usr/lib/libresolv.9.dylib (compatibility version 0.0.0, current 
version 0.0.0)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security 
(compatibility version 0.0.0, current version 0.0.0)

On Friday, February 9, 2024 at 2:22:36 PM UTC+1 Brian Candler wrote:

> Have you at any point set CGO_ENABLED=0 ?
>
> What does "ldd /path/to/binary" show on both the old (larger) and new 
> (smaller) binaries?  Maybe one is dynamically linked and the other 
> statically linked?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5787a122-8581-41e7-81d5-9ae2b0e28942n%40googlegroups.com.

[go-nuts] How to add labels to Go runtime prometheus metrics?

[cpu...@gmail.com]

The Go runtime exposes various metrics. To collect metrics from multiple 
servers I'd like to add labels for server name. Is it possible to extend 
the build-in metrics for this purpose?

Thanks,
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/84c1dde1-938e-4e6d-9143-4ca290608839n%40googlegroups.com.

[go-nuts] Re: How to add labels to Go runtime prometheus metrics?

[cpu...@gmail.com]

Situation here may be a bit specific. Running 2 cloud machines behind 
reverse proxy. I realise this is per chance if the proxy will hit any of 
the two, but that would be good enough id I could distinguish their metrics.

On Wednesday, March 6, 2024 at 1:38:12 PM UTC+1 Brian Candler wrote:

> The server name will be added by Prometheus itself as an "instance" label 
> for each target being scraped (or you can manually set the instance label 
> for each target), so in general what you're asking is not necessary.  None 
> of the standard Prometheus exporters include a label for the hostname (e.g. 
> node_exporter, windows_exporter etc).
>
> If there's something special about your situation which means you need to 
> do this, can you explain your use case further?
>
> On Wednesday 6 March 2024 at 10:40:29 UTC cpu...@gmail.com wrote:
>
>> The Go runtime exposes various metrics. To collect metrics from multiple 
>> servers I'd like to add labels for server name. Is it possible to extend 
>> the build-in metrics for this purpose?
>>
>> Thanks,
>> 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/d2bd9a84-e075-46cc-804c-6a67b8e39383n%40googlegroups.com.

[go-nuts] Where is my type?

[cpu...@gmail.com]

Every time I feel I've come to terms with how Go works I round a corner and 
hit a wall, even after doing this for >5 years. Here's one.

Consider this simple code (https://go.dev/play/p/bph5I80vc99):

package main

import (
"encoding/json"
"fmt"
)

type S struct {
Foo int
}

func update(v any) {
if err := json.Unmarshal([]byte(`{"Foo": 42}`), &v); err != nil {
panic(err)
}
fmt.Printf("%v %T\n", v, v)
}

func main() {
var val S

// map[Foo:42] map[string]interface {}
update(val)

// &{42} *main.S
update(&val)
}

Why would calling by value change the type of the value passed to map? I 
would expect an interface with a dynamic type of main.S, but its 
map[string]interface{}, or json.Unmarshal makes it so.

Insights appreciated :)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/980466d2-1686-4b79-aec1-45b592db2caan%40googlegroups.com.

[go-nuts] Re: Where is my type?

[cpu...@gmail.com]

It's worth noting that before the Unmarshal v is {}(main.S) and afterwards 
{}(map[string]interface{}) 
On Wednesday, April 24, 2024 at 6:46:18 PM UTC+2 cpu...@gmail.com wrote:

> Every time I feel I've come to terms with how Go works I round a corner 
> and hit a wall, even after doing this for >5 years. Here's one.
>
> Consider this simple code (https://go.dev/play/p/bph5I80vc99):
>
> package main
>
> import (
> "encoding/json"
> "fmt"
> )
>
> type S struct {
> Foo int
> }
>
> func update(v any) {
> if err := json.Unmarshal([]byte(`{"Foo": 42}`), &v); err != nil {
> panic(err)
> }
> fmt.Printf("%v %T\n", v, v)
> }
>
> func main() {
> var val S
>
> // map[Foo:42] map[string]interface {}
> update(val)
>
> // &{42} *main.S
> update(&val)
> }
>
> Why would calling by value change the type of the value passed to map? I 
> would expect an interface with a dynamic type of main.S, but its 
> map[string]interface{}, or json.Unmarshal makes it so.
>
> Insights appreciated :)
>

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

Re: [go-nuts] Where is my type?

[cpu...@gmail.com]

> In the first case, the interface contains a value of type S, which is not 
writable. The value contained in the interface is not addressable.

Thank you for the quick feedback. 
Why is that? Memory for val has been allocated and val is passed by value 
(hence copied). Why is that copy not be addressable?

On Wednesday, April 24, 2024 at 6:51:21 PM UTC+2 burak serdar wrote:

> In the first case, the interface contains a value of type S, which is
> not writable. The value contained in the interface is not addressable.
> So Unmarshal creates a new map and fills that. In the second case the
> interface contains *S, which is writable, so unmarshal fills it in via
> reflection.
>
> On Wed, Apr 24, 2024 at 10:46 AM cpu...@gmail.com  
> wrote:
> >
> > Every time I feel I've come to terms with how Go works I round a corner 
> and hit a wall, even after doing this for >5 years. Here's one.
> >
> > Consider this simple code (https://go.dev/play/p/bph5I80vc99):
> >
> > package main
> >
> > import (
> > "encoding/json"
> > "fmt"
> > )
> >
> > type S struct {
> > Foo int
> > }
> >
> > func update(v any) {
> > if err := json.Unmarshal([]byte(`{"Foo": 42}`), &v); err != nil {
> > panic(err)
> > }
> > fmt.Printf("%v %T\n", v, v)
> > }
> >
> > func main() {
> > var val S
> >
> > // map[Foo:42] map[string]interface {}
> > update(val)
> >
> > // &{42} *main.S
> > update(&val)
> > }
> >
> > Why would calling by value change the type of the value passed to map? I 
> would expect an interface with a dynamic type of main.S, but its 
> map[string]interface{}, or json.Unmarshal makes it so.
> >
> > Insights appreciated :)
> >
> > --
> > You received this message because you are subscribed 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/980466d2-1686-4b79-aec1-45b592db2caan%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/ec00ba73-b91e-4a1c-a5ed-4d5507a90c18n%40googlegroups.com.

Re: [go-nuts] Where is my type?

[cpu...@gmail.com]

Your answer has put me on the right track. Here's the long 
version: 
https://stackoverflow.com/questions/48790663/why-value-stored-in-an-interface-is-not-addressable-in-golang

On Wednesday, April 24, 2024 at 6:55:53 PM UTC+2 cpu...@gmail.com wrote:

> > In the first case, the interface contains a value of type S, which is 
> not writable. The value contained in the interface is not addressable.
>
> Thank you for the quick feedback. 
> Why is that? Memory for val has been allocated and val is passed by value 
> (hence copied). Why is that copy not be addressable?
>
> On Wednesday, April 24, 2024 at 6:51:21 PM UTC+2 burak serdar wrote:
>
>> In the first case, the interface contains a value of type S, which is 
>> not writable. The value contained in the interface is not addressable. 
>> So Unmarshal creates a new map and fills that. In the second case the 
>> interface contains *S, which is writable, so unmarshal fills it in via 
>> reflection. 
>>
>> On Wed, Apr 24, 2024 at 10:46 AM cpu...@gmail.com  
>> wrote: 
>> > 
>> > Every time I feel I've come to terms with how Go works I round a corner 
>> and hit a wall, even after doing this for >5 years. Here's one. 
>> > 
>> > Consider this simple code (https://go.dev/play/p/bph5I80vc99): 
>> > 
>> > package main 
>> > 
>> > import ( 
>> > "encoding/json" 
>> > "fmt" 
>> > ) 
>> > 
>> > type S struct { 
>> > Foo int 
>> > } 
>> > 
>> > func update(v any) { 
>> > if err := json.Unmarshal([]byte(`{"Foo": 42}`), &v); err != nil { 
>> > panic(err) 
>> > } 
>> > fmt.Printf("%v %T\n", v, v) 
>> > } 
>> > 
>> > func main() { 
>> > var val S 
>> > 
>> > // map[Foo:42] map[string]interface {} 
>> > update(val) 
>> > 
>> > // &{42} *main.S 
>> > update(&val) 
>> > } 
>> > 
>> > Why would calling by value change the type of the value passed to map? 
>> I would expect an interface with a dynamic type of main.S, but its 
>> map[string]interface{}, or json.Unmarshal makes it so. 
>> > 
>> > Insights appreciated :) 
>> > 
>> > -- 
>> > You received this message because you are subscribed 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/980466d2-1686-4b79-aec1-45b592db2caan%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/0010deaa-b3c9-4323-a1f4-d0dc3eec3c78n%40googlegroups.com.

[go-nuts] Programming patterns: storing runtime configuration

[cpu...@gmail.com]

Hope the question is not too OT for this group, if yes please just ignore 
it and forgive me.

We're in the progress of migrating a somewhat-complex application 
(https://github.com/evcc-io/evcc) from static, yaml-based configuration to 
fully UI-controllable dynamic config. A running application manages some 
5-20 configurable objects. Using yaml, config was just public properties of 
structs manages by yaml.Unmarshal. We could continue doing so and maybe use 
json.(Un)Marshal to put the identical structs into a database table, but it 
feels odd to have public properties in objects/structs just for the purpose 
of storing an manipulating their configuration.

What are good patterns for managing runtime config and is there any project 
you can recommend to look at that does this particularly well or elegant?

Thanks,
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/8a218694-a309-458c-89b5-724a4610017fn%40googlegroups.com.

[go-nuts] Working with release candidates

[cpu...@gmail.com]

I'm preparing our application for go1.24, including using the tools go.mod 
directive. I was expecting that I should be able to require rc1 as part of 
the build process. However, adding 

go 1.24rc1
toolchain 1.24rc1

lead to either

unknown block type: tool
invalid toolchain version '1.24rc1': must match format go1.23.0 or default

https://go.dev/doc/modules/gomod-ref does not mention RC versions, 
while https://go.dev/doc/toolchain does.

Can RC versions be required through go.mod?

Thanks,
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 visit 
https://groups.google.com/d/msgid/golang-nuts/fc8ed520-8f24-4566-a58b-0e41ee5238b7n%40googlegroups.com.

[go-nuts] Re: Working with release candidates

[cpu...@gmail.com]

I already did- that's the first error message:

go: errors parsing go.mod:
go.mod:206: unknown block type: tool

It seems that the forward compatibility does not work when the go.mod 
contains new sections as it fails to parse _before_ the actual Go version 
selection happens?

On Thursday, December 19, 2024 at 7:54:21 PM UTC+1 Alex Bozhenko wrote:

> You missed go:
> go 1.24rc1
> toolchain go1.24rc1
>
>
> Go toolchain names¶ <https://go.dev/doc/toolchain#name> 
>
> The standard Go toolchains are named go*V* where *V* is a Go version 
> denoting a beta release, release candidate, or release. For example, 
> go1.21rc1 and...
>
> Once you build, you can verify which version was used:
> go version ./your_binary
> https://tip.golang.org/doc/toolchain#config
> > If the toolchain line is omitted, the module or workspace is considered 
> to have an implicit toolchain go*V* line, where *V* is the Go version 
> from the go line.
>
> So you only need to use 'go 1.24rc1' line.
>
> On Thursday, December 19, 2024 at 4:30:40 AM UTC-8 cpu...@gmail.com wrote:
>
>> I'm preparing our application for go1.24, including using the tools 
>> go.mod directive. I was expecting that I should be able to require rc1 as 
>> part of the build process. However, adding 
>>
>> go 1.24rc1
>> toolchain 1.24rc1
>>
>> lead to either
>>
>> unknown block type: tool
>> invalid toolchain version '1.24rc1': must match format go1.23.0 or default
>>
>> https://go.dev/doc/modules/gomod-ref does not mention RC versions, while 
>> https://go.dev/doc/toolchain does.
>>
>> Can RC versions be required through go.mod?
>>
>> Thanks,
>> 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 visit 
https://groups.google.com/d/msgid/golang-nuts/0205f49b-9aca-442f-bedf-9509e87b08d5n%40googlegroups.com.

Re: [go-nuts] Re: Working with release candidates

[cpu...@gmail.com]

Opened https://github.com/golang/go/issues/70949

On Friday, December 20, 2024 at 10:57:50 PM UTC+1 Michael Pratt wrote:

> Could you file an issue about this with reproduction steps? My attempt to 
> reproduce this works fine.
>
> go.mod
>
> ```
> module example.com
>
> go 1.24rc1
>
> tool (
> golang.org/x/tools/cmd/stringer
> golang.org/x/tools/cmd/toolstash
> )
>
> require (
> golang.org/x/mod v0.22.0 // indirect
> golang.org/x/sync v0.10.0 // indirect
> golang.org/x/tools v0.28.0 // indirect
> )
> ```
>
> $ go version  # go binary is 1.23
> go: downloading go1.24rc1 (linux/amd64)
> go version go1.24rc1 linux/amd64
>
> On Fri, Dec 20, 2024 at 5:11 PM cpu...@gmail.com  wrote:
>
>> I already did- that's the first error message:
>>
>> go: errors parsing go.mod:
>> go.mod:206: unknown block type: tool
>>
>> It seems that the forward compatibility does not work when the go.mod 
>> contains new sections as it fails to parse _before_ the actual Go version 
>> selection happens?
>>
>> On Thursday, December 19, 2024 at 7:54:21 PM UTC+1 Alex Bozhenko wrote:
>>
>>> You missed go:
>>> go 1.24rc1
>>> toolchain go1.24rc1
>>>
>>>
>>> Go toolchain names¶ <https://go.dev/doc/toolchain#name> 
>>>
>>> The standard Go toolchains are named go*V* where *V* is a Go version 
>>> denoting a beta release, release candidate, or release. For example, 
>>> go1.21rc1 and...
>>>
>>> Once you build, you can verify which version was used:
>>> go version ./your_binary
>>> https://tip.golang.org/doc/toolchain#config
>>> > If the toolchain line is omitted, the module or workspace is 
>>> considered to have an implicit toolchain go*V* line, where *V* is the 
>>> Go version from the go line.
>>>
>>> So you only need to use 'go 1.24rc1' line.
>>>
>>> On Thursday, December 19, 2024 at 4:30:40 AM UTC-8 cpu...@gmail.com 
>>> wrote:
>>>
>>>> I'm preparing our application for go1.24, including using the tools 
>>>> go.mod directive. I was expecting that I should be able to require rc1 as 
>>>> part of the build process. However, adding 
>>>>
>>>> go 1.24rc1
>>>> toolchain 1.24rc1
>>>>
>>>> lead to either
>>>>
>>>> unknown block type: tool
>>>> invalid toolchain version '1.24rc1': must match format go1.23.0 or 
>>>> default
>>>>
>>>> https://go.dev/doc/modules/gomod-ref does not mention RC versions, 
>>>> while https://go.dev/doc/toolchain does.
>>>>
>>>> Can RC versions be required through go.mod?
>>>>
>>>> Thanks,
>>>> 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...@googlegroups.com.
>> To view this discussion visit 
>> https://groups.google.com/d/msgid/golang-nuts/0205f49b-9aca-442f-bedf-9509e87b08d5n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/0205f49b-9aca-442f-bedf-9509e87b08d5n%40googlegroups.com?utm_medium=email&utm_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 visit 
https://groups.google.com/d/msgid/golang-nuts/1debcfa8-7927-438b-9f89-d56954495736n%40googlegroups.com.

[go-nuts] Using errors.As error-prone

[cpu...@gmail.com]

I've had some ongoing confusion about using errors.As 
(see https://play.golang.com/p/m4_cXCzOViD). The issue I'm having is this 
part of the contract:

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

I always expected (yes, I know), that base and pointer receivers are 
interchangeable. This is not the case (see playground). This seems to make 
using it error-prone as you'll always need to carefully think about the 
return type of the function invoked. While the contract is always error, a 
function may return a base or a pointer error type. This influences how 
using errors.As must be done.

Are there best practices for:
- return base vs. pointer errors
- crafting  the errors.As target type without inspecting the actual 
function invoked

...and could it make sense to lessen errors.As to match pointer with 
non-pointer receivers?

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 visit 
https://groups.google.com/d/msgid/golang-nuts/afe2df8a-9e42-4511-abe6-8e03b906d637n%40googlegroups.com.

[go-nuts] Logging best practices with log/slog

[cpu...@gmail.com]

I'm in the process of converting our application (evcc.io) from using 
spf13/jwalterweatherman for logging to log/slog. One current pain point is 
passing loggers around the application and deriving child loggers. With 
using slog there are various options for doing that:

Passing loggers:

   - pass parent logger as parameter
   - pass a context and retrieve the parent logger from context value
   

Passing log attributes/groups to child loggers:

   - assign them to loggers and pass them via the logger (see before- 
   either as parameter or context value)
   - assign them to context and retrieve them from context value for 
   assigning to the child logger
   
Not sure those questions are clear enough, but let's try: are there 
experiences what works "best" in larger applications?

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 visit 
https://groups.google.com/d/msgid/golang-nuts/38bf1b02-3c20-4912-804f-ac200326e2cen%40googlegroups.com.

[go-nuts] Why can't single-method interfaces not be implemented by embedding?

[cpu...@gmail.com]

About every single time I feel like I understand Go interfaces I'm being 
taught differently.

Consider this play: https://play.golang.com/p/qeF4KvaPcwp

There are 2 single method interfaces. One where interface and method names 
are equal, one where they are different.

I would have expected m to implement both interfaces, but it doesn't. Why 
is that?

Thanks,
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 visit 
https://groups.google.com/d/msgid/golang-nuts/22aaa13f-41d9-4d4c-93c8-455faaef50c2n%40googlegroups.com.

Re: [go-nuts] Why can't single-method interfaces not be implemented by embedding?

[cpu...@gmail.com]

Thanks Ian, you are of course correct- but I still don't get it. Thank you 
for taking the time.

> m.EqualName has to mean something. The Go language defines it as
meaning the field in m's type, rather than the embedded method.

Doesn't have meter an embedded field of type EqualName (the interface)?

> Therefore, the type meter does not have a method EqualName. Therefore,
the type meter does not implement the EqualName interface.

meter doesn't. But impl's methods get promoted to meter- which happens with 
different name: clearly the different name method has become promoted, 
implements the different namer interface and is non-nil.

I still don't fully understand why this doesn't work for equal name. If 
impl's equal name method does get promoted it should implement the 
interface since meter now as a equal name method. If it doesn't (due to 
name conflict with the embedded equal name interface) where would still be 
the embedded equal name interface (which might be nil but still existing)?

Thanks,
Andi

On Thursday, February 27, 2025 at 6:40:30 PM UTC+1 Ian Lance Taylor wrote:

> On Thu, Feb 27, 2025 at 9:32 AM cpu...@gmail.com  wrote:
> >
> > I can see that that's the difference and cause but I'm not convinced by 
> the explanation (although that clearly is what happens):
> >
> > If the embedded method name EqualName shadows the method name EqualName 
> that should still implement the interface of the same signature? I.e. why 
> doesn't the shadow implement the interface?
>
> I'm sorry, I don't understand the question. I'll try to explain what
> is happening.
>
> m.EqualName has to mean something. The Go language defines it as
> meaning the field in m's type, rather than the embedded method.
> Therefore, the type meter does not have a method EqualName. Therefore,
> the type meter does not implement the EqualName interface.
>
> I note that this kind of confusion between interface name and method
> name is the Go standard library is careful to do things like an
> interface Writer with a method Write. We don't use the same name for
> an interface type and the method(s) that it includes.
>
> 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 visit 
https://groups.google.com/d/msgid/golang-nuts/1a4bf2ee-f1ae-4ff2-9829-38506870cad9n%40googlegroups.com.

Re: [go-nuts] Why does this channel-based pub/sub broker panic?

[cpu...@gmail.com]

Thanks Jan, but this just confirms that there is a send on a closed 
channel. 

It makes me wonder though (far, very far shot): given the map of 
subscriptions is using the new swissmap, might that be a bug with that? As 
I've said- very long shot.

Cheers,
Andi

On Tuesday, March 4, 2025 at 2:51:41 PM UTC+1 Jan Mercl wrote:

> On Tue, Mar 4, 2025 at 2:41 PM cpu...@gmail.com  wrote:
>
> > I've recently run across 
> https://stackoverflow.com/questions/36417199/how-to-broadcast-message-using-channel
>  
> by icza and tried to use the simple broker in my project.
> >
> > Unfortunately, it panics with send on closed channel. I couldn't figure 
> out why or where and created a reproducer: 
> https://play.golang.com/p/8hrHf4-nGY2
> >
> > Can someone spot why this would panic (except for the obvious reason) 
> and how to fix it?
>
> I didn't analyze the code, but maybe this can help:
> https://play.golang.com/p/Ix003aXFFul
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/golang-nuts/c1a2ed5f-6b94-4acc-8d8f-465131e74651n%40googlegroups.com.

Re: [go-nuts] Why does this channel-based pub/sub broker panic?

[cpu...@gmail.com]

Great find, confirmed. Since subscribe is not executed synchronously due to 
buffering, unsubscribe may execute first, close the channel, and then 
subscribes puts the closed channel into the subscriptions.

THANK YOU!

On Tuesday, March 4, 2025 at 3:39:43 PM UTC+1 Robert Engels wrote:

> I figured it out. Because the subscribe channel is buffered. Technically 
> the broker can see the unsubscribe for the client before the subscribe 
> message. So it closes the channel then tries to send on it. 
>
> On Mar 4, 2025, at 8:23 AM, cpu...@gmail.com  wrote:
>
> Thanks Robert,
>
> with unbuffered channels it doesn't panic- but the play also doesn't end. 
> Debugger confirms "all go routines asleep" (not sure why).
> I'd also still be confused why the (un)subscribe channels should matter. 
> As long as (in unsubscribe) the msgCh hasn't been removed it can still be 
> sent to, buffering wouldn't change that.
>
> Thanks for your interest in chasing this :)
>
> Cheers,
> Andi
> On Tuesday, March 4, 2025 at 3:09:11 PM UTC+1 Robert Engels wrote:
>
>> Actually all if the channels need to be unbuffered. Otherwise you have 
>> pending data that isn’t read when the channel is closed. When I make them 
>> all unbuffered it works. 
>>
>> On Mar 4, 2025, at 8:04 AM, cpu...@gmail.com  wrote:
>>
>> Thanks Robert,
>>
>>
>> did a quick try and still panics. This seems to make sense- the 
>> unsubscribe is the root cause of the panic- while it's still in the buffer 
>> the channel won't be closed.
>>
>> Cheers,
>> Andi
>>
>> On Tuesday, March 4, 2025 at 3:01:37 PM UTC+1 Robert Engels wrote:
>>
>>> You can’t make the unsubscribe channel buffered. 
>>>
>>> On Mar 4, 2025, at 7:55 AM, cpu...@gmail.com  wrote:
>>>
>>> Thanks Jan, but this just confirms that there is a send on a closed 
>>> channel. 
>>>
>>>
>>> It makes me wonder though (far, very far shot): given the map of 
>>> subscriptions is using the new swissmap, might that be a bug with that? As 
>>> I've said- very long shot.
>>>
>>> Cheers,
>>> Andi
>>>
>>> On Tuesday, March 4, 2025 at 2:51:41 PM UTC+1 Jan Mercl wrote:
>>>
>>>> On Tue, Mar 4, 2025 at 2:41 PM cpu...@gmail.com  
>>>> wrote: 
>>>>
>>>> > I've recently run across 
>>>> https://stackoverflow.com/questions/36417199/how-to-broadcast-message-using-channel
>>>>  
>>>> by icza and tried to use the simple broker in my project. 
>>>> > 
>>>> > Unfortunately, it panics with send on closed channel. I couldn't 
>>>> figure out why or where and created a reproducer: 
>>>> https://play.golang.com/p/8hrHf4-nGY2 
>>>> > 
>>>> > Can someone spot why this would panic (except for the obvious reason) 
>>>> and how to fix it? 
>>>>
>>>> I didn't analyze the code, but maybe this can help: 
>>>> https://play.golang.com/p/Ix003aXFFul 
>>>>
>>> -- 
>>> You received this message because you are subscribed 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 visit 
>>> https://groups.google.com/d/msgid/golang-nuts/c1a2ed5f-6b94-4acc-8d8f-465131e74651n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/c1a2ed5f-6b94-4acc-8d8f-465131e74651n%40googlegroups.com?utm_medium=email&utm_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...@googlegroups.com.
>>
>> To view this discussion visit 
>> https://groups.google.com/d/msgid/golang-nuts/8e554048-40cd-48bb-91f8-d56ade4a32a7n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/8e554048-40cd-48bb-91f8-d56ade4a32a7n%40googlegroups.com?utm_medium=email&utm_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...@googlegroups.com.
>
> To view this discussion visit 
> https://groups.google.com/d/msgid/golang-nuts/bc94988b-63b6-43f0-8db0-ad3b1cef8e67n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/bc94988b-63b6-43f0-8db0-ad3b1cef8e67n%40googlegroups.com?utm_medium=email&utm_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 visit 
https://groups.google.com/d/msgid/golang-nuts/97716779-a51c-4fc6-9b3e-3c3e7a8b22ebn%40googlegroups.com.

[go-nuts] Why does this channel-based pub/sub broker panic?

[cpu...@gmail.com]

I've recently run 
across  
https://stackoverflow.com/questions/36417199/how-to-broadcast-message-using-channel
 
by icza and tried to use the simple broker in my project.

Unfortunately, it panics with send on closed channel. I couldn't figure out 
why or where and created a reproducer: https://play.golang.com/p/8hrHf4-nGY2

Can someone spot why this would panic (except for the obvious reason) and 
how to fix it?

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 visit 
https://groups.google.com/d/msgid/golang-nuts/31195186-a8dd-4b0f-8aab-ae358bd197f1n%40googlegroups.com.

Re: [go-nuts] Why does this channel-based pub/sub broker panic?

[cpu...@gmail.com]

Thanks Robert,

with unbuffered channels it doesn't panic- but the play also doesn't end. 
Debugger confirms "all go routines asleep" (not sure why).
I'd also still be confused why the (un)subscribe channels should matter. As 
long as (in unsubscribe) the msgCh hasn't been removed it can still be sent 
to, buffering wouldn't change that.

Thanks for your interest in chasing this :)

Cheers,
Andi
On Tuesday, March 4, 2025 at 3:09:11 PM UTC+1 Robert Engels wrote:

> Actually all if the channels need to be unbuffered. Otherwise you have 
> pending data that isn’t read when the channel is closed. When I make them 
> all unbuffered it works. 
>
> On Mar 4, 2025, at 8:04 AM, cpu...@gmail.com  wrote:
>
> Thanks Robert,
>
>
> did a quick try and still panics. This seems to make sense- the 
> unsubscribe is the root cause of the panic- while it's still in the buffer 
> the channel won't be closed.
>
> Cheers,
> Andi
>
> On Tuesday, March 4, 2025 at 3:01:37 PM UTC+1 Robert Engels wrote:
>
>> You can’t make the unsubscribe channel buffered. 
>>
>> On Mar 4, 2025, at 7:55 AM, cpu...@gmail.com  wrote:
>>
>> Thanks Jan, but this just confirms that there is a send on a closed 
>> channel. 
>>
>>
>> It makes me wonder though (far, very far shot): given the map of 
>> subscriptions is using the new swissmap, might that be a bug with that? As 
>> I've said- very long shot.
>>
>> Cheers,
>> Andi
>>
>> On Tuesday, March 4, 2025 at 2:51:41 PM UTC+1 Jan Mercl wrote:
>>
>>> On Tue, Mar 4, 2025 at 2:41 PM cpu...@gmail.com  
>>> wrote: 
>>>
>>> > I've recently run across 
>>> https://stackoverflow.com/questions/36417199/how-to-broadcast-message-using-channel
>>>  
>>> by icza and tried to use the simple broker in my project. 
>>> > 
>>> > Unfortunately, it panics with send on closed channel. I couldn't 
>>> figure out why or where and created a reproducer: 
>>> https://play.golang.com/p/8hrHf4-nGY2 
>>> > 
>>> > Can someone spot why this would panic (except for the obvious reason) 
>>> and how to fix it? 
>>>
>>> I didn't analyze the code, but maybe this can help: 
>>> https://play.golang.com/p/Ix003aXFFul 
>>>
>> -- 
>> You received this message because you are subscribed 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 visit 
>> https://groups.google.com/d/msgid/golang-nuts/c1a2ed5f-6b94-4acc-8d8f-465131e74651n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/c1a2ed5f-6b94-4acc-8d8f-465131e74651n%40googlegroups.com?utm_medium=email&utm_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...@googlegroups.com.
>
> To view this discussion visit 
> https://groups.google.com/d/msgid/golang-nuts/8e554048-40cd-48bb-91f8-d56ade4a32a7n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/8e554048-40cd-48bb-91f8-d56ade4a32a7n%40googlegroups.com?utm_medium=email&utm_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 visit 
https://groups.google.com/d/msgid/golang-nuts/bc94988b-63b6-43f0-8db0-ad3b1cef8e67n%40googlegroups.com.

Re: [go-nuts] Why does this channel-based pub/sub broker panic?

[cpu...@gmail.com]

Thanks Robert,

did a quick try and still panics. This seems to make sense- the unsubscribe 
is the root cause of the panic- while it's still in the buffer the channel 
won't be closed.

Cheers,
Andi

On Tuesday, March 4, 2025 at 3:01:37 PM UTC+1 Robert Engels wrote:

> You can’t make the unsubscribe channel buffered. 
>
> On Mar 4, 2025, at 7:55 AM, cpu...@gmail.com  wrote:
>
> Thanks Jan, but this just confirms that there is a send on a closed 
> channel. 
>
>
> It makes me wonder though (far, very far shot): given the map of 
> subscriptions is using the new swissmap, might that be a bug with that? As 
> I've said- very long shot.
>
> Cheers,
> Andi
>
> On Tuesday, March 4, 2025 at 2:51:41 PM UTC+1 Jan Mercl wrote:
>
>> On Tue, Mar 4, 2025 at 2:41 PM cpu...@gmail.com  
>> wrote: 
>>
>> > I've recently run across 
>> https://stackoverflow.com/questions/36417199/how-to-broadcast-message-using-channel
>>  
>> by icza and tried to use the simple broker in my project. 
>> > 
>> > Unfortunately, it panics with send on closed channel. I couldn't figure 
>> out why or where and created a reproducer: 
>> https://play.golang.com/p/8hrHf4-nGY2 
>> > 
>> > Can someone spot why this would panic (except for the obvious reason) 
>> and how to fix it? 
>>
>> I didn't analyze the code, but maybe this can help: 
>> https://play.golang.com/p/Ix003aXFFul 
>>
> -- 
> You received this message because you are subscribed 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 visit 
> https://groups.google.com/d/msgid/golang-nuts/c1a2ed5f-6b94-4acc-8d8f-465131e74651n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/c1a2ed5f-6b94-4acc-8d8f-465131e74651n%40googlegroups.com?utm_medium=email&utm_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 visit 
https://groups.google.com/d/msgid/golang-nuts/8e554048-40cd-48bb-91f8-d56ade4a32a7n%40googlegroups.com.

Re: [go-nuts] Why can't single-method interfaces not be implemented by embedding?

[cpu...@gmail.com]

I can see that that's the difference and cause but I'm not convinced by the 
explanation (although that clearly is what happens):

If the embedded method name EqualName shadows the method name EqualName 
that should still implement the interface of the same signature? I.e. why 
doesn't the shadow implement the interface?

On Thursday, February 27, 2025 at 6:28:16 PM UTC+1 burak serdar wrote:

> The embedded name `EqualName` shahows the method called `EqualName`.
>
> Rename the `EqualName` interface to `EqualNamer`, and things work.
>
>
> On Thu, Feb 27, 2025 at 10:07 AM cpu...@gmail.com  
> wrote:
> >
> > About every single time I feel like I understand Go interfaces I'm being 
> taught differently.
> >
> > Consider this play: https://play.golang.com/p/qeF4KvaPcwp
> >
> > There are 2 single method interfaces. One where interface and method 
> names are equal, one where they are different.
> >
> > I would have expected m to implement both interfaces, but it doesn't. 
> Why is that?
> >
> > Thanks,
> > 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...@googlegroups.com.
> > To view this discussion visit 
> https://groups.google.com/d/msgid/golang-nuts/22aaa13f-41d9-4d4c-93c8-455faaef50c2n%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 visit 
https://groups.google.com/d/msgid/golang-nuts/bd048d4e-b0ab-41cb-ae4b-4bb75fa73973n%40googlegroups.com.

Re: [go-nuts] Why can't single-method interfaces not be implemented by embedding?

[cpu...@gmail.com]

Thank you Axel for quoting the spec.

On Thursday, February 27, 2025 at 10:55:58 PM UTC+1 Axel Wagner wrote:

> For a value x of type T or *T where T is not a pointer or interface type, 
x.f denotes the field or method *at the shallowest depth* in T where there 
is such an f. If there is not exactly one f with shallowest depth, the 
selector expression is illegal.

The field `meter.EqualName` has a more shallow depth than 
`meter.EqualName.EqualName`, thus `m.EqualName` denotes the field, not the 
method.
Thus, the method is not promoted. Thus `meter` has no `EqualName` method, 
as the only way it could get one is by promotion.


I can see why the EqualName method is not promoted. However, there is still 
the EqualName field. Even if it's not useful (since zero value) I would 
expect this fields to make meter implement the EqualName interface. See 
https://play.golang.com/p/awtbP1X93Pg for an example that shows that 
presence of an interface field is enough.

Thanks,
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 visit 
https://groups.google.com/d/msgid/golang-nuts/b4d16a1e-1c31-4cbb-8774-fc7b9d960d5fn%40googlegroups.com.

Re: [go-nuts] LLM development toolkit.

[cpu...@gmail.com]

Zip files are impossible to reason about on Github and a potential security 
thread. I'd not even try to find out what might be inside...

On Tuesday, February 18, 2025 at 1:40:43 PM UTC+1 alex-coder wrote:

> Hi All,
>
> I was given a shelter there:
> gussev/llm: 
>
> In case someone is in interest of course. :-)
>
> Thank you.
>
> вторник, 28 января 2025 г. в 19:45:53 UTC+3, alex-coder: 
>
>> Hi All !
>> Recently I have made a step towards to the first letter in LLM 
>> abbreviation - Large. That means that soft now could work with LLM data 
>> model is located in file system and only take into RAM data which one is 
>> necessary to compute result.
>> But unfortunately so far I'm not able to pass 2FA to deploy newest 
>> version. :-) 
>> So, in case someone is in interest drop me a message I'll send you a new 
>> version.
>> News:
>> file config. There are added two parameters:
>> 1. "store" has two options "ram" and "file", tells to the llm where to 
>> keep data model in ram or in a file system.
>> 2. "capacity" - the maximum size for each of the files where llm would 
>> keep information for the data model. 
>> memo: default file size would be 16384 but in reality the file size will 
>> be 3 times more, do not be afraid, this is my fault.
>>
>> Thank you.
>>
>> ps. in case I will not be able to pass a 2FA for github.com I have to 
>> find another place to deploy my page. :-) Thank you again.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/golang-nuts/cb3c3294-f881-44ed-92c8-db32272dc98an%40googlegroups.com.

Re: [go-nuts] Using errors.As error-prone

[cpu...@gmail.com]

> The best practice is pointer errors.

If that is an accepted best practice, wouldn't it make sense to have a go 
vet or linter check that verifies that (at least for public error types)?
It is really not visible from the api and developers will only start 
thinking about it once they have been bitten.

Imho this needs much better tooling.

On Wednesday, February 12, 2025 at 10:06:08 AM UTC+1 Axel Wagner wrote:

> On Wed, 12 Feb 2025 at 09:21, cpu...@gmail.com  wrote:
>
>> I've had some ongoing confusion about using errors.As (see 
>> https://play.golang.com/p/m4_cXCzOViD). The issue I'm having is this 
>> part of the contract:
>>
>> > An error matches target if the error's concrete value is assignable to 
>> the value pointed to by target
>>
>> I always expected (yes, I know), that base and pointer receivers are 
>> interchangeable. This is not the case (see playground). This seems to make 
>> using it error-prone as you'll always need to carefully think about the 
>> return type of the function invoked. While the contract is always error, a 
>> function may return a base or a pointer error type. This influences how 
>> using errors.As must be done.
>>
>> Are there best practices for:
>> - return base vs. pointer errors
>>
>
> The best practice is pointer errors. I would have personally preferred to 
> live in a world where value errors are better (in particular, it would be 
> pretty nice to be able to compare full error values using `==` in tests). 
> But the issue you have discovered is pretty much exactly, why pointer 
> errors are better.
>
> If you declare `Error()` on a value receiver, then both `err.(YourErr)` 
> and `err.(*YourErr)` will compile just fine, as value-methods are promoted 
> to the pointer type. But only one of them will succeed. Similarly, both 
> `return YourErr{…}` and `return &YourErr{…}` will compile. So it is 
> somewhat easy to make a mistake that are then hard to debug in practice - 
> and the error paths tend to be badly tested already.
>
> If, on the other hand, you declare it with a pointer receiver, only 
> `err.(*YourErr)` and `return &YourErr{…}` will compile. Meaning the 
> compiler ensures that you write the correct code.
>
> errors.As is ultimately a dynamic extension of this semantic difference, 
> which is the problem you have stumbled on.
>  
>
>> - crafting  the errors.As target type without inspecting the actual 
>> function invoked
>>
>> ...and could it make sense to lessen errors.As to match pointer with 
>> non-pointer receivers?
>>
>> 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 visit 
>> https://groups.google.com/d/msgid/golang-nuts/afe2df8a-9e42-4511-abe6-8e03b906d637n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/afe2df8a-9e42-4511-abe6-8e03b906d637n%40googlegroups.com?utm_medium=email&utm_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 visit 
https://groups.google.com/d/msgid/golang-nuts/7fd760d4-acce-4562-9ded-defa180f5c18n%40googlegroups.com.

[go-nuts] Why does using time.Time.Compare like this work?

[cpu...@gmail.com]

Sorry for not finding a better than this click bait subject. 

In https://github.com/golang/go/issues/62642 this suggestion was made:

slices.SortFunc(times, time.Time.Compare)

It's totally unclear to me how Time.Compare matches the compare func(a,b T) 
int signature? I assume it's something from the golang spec, but which part?

Are there other typical uses of this capability that are common?

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 visit 
https://groups.google.com/d/msgid/golang-nuts/efe0eaf6-576b-4cdc-b476-8980eb562f61n%40googlegroups.com.

[go-nuts] Re: Why does using time.Time.Compare like this work?

[cpu...@gmail.com]

All great answers and thank you for the spec link!

On Thursday, February 20, 2025 at 8:07:42 PM UTC+1 Diogo Lisboa wrote:

> You have to remember that methods are just regular functions with the 
> receiver as the first parameter. From the spec (
> https://go.dev/ref/spec#Method_declarations):
>
> > A method is a function <https://go.dev/ref/spec#Function_declarations> with 
> a receiver.
>
> This mean that if you detach the method from the receiver, which 
> time.Time.Compare does, then it requires two arguments instead of one.
>
> a := time.Now()
> b := a.Add(1 * time.Hour)
> cmp := time.Time.Compare
> cmp(a) // error: not enough arguments in call to cmp
> cmp(a, b) // ok
>
> https://go.dev/play/p/x3ZGIhQ2TNE
>
>
> Diogo Lisboa
>
> On Thursday, February 20, 2025 at 2:57:35 PM UTC-3 cpu...@gmail.com wrote:
>
>> Sorry for not finding a better than this click bait subject. 
>>
>> In https://github.com/golang/go/issues/62642 this suggestion was made:
>>
>> slices.SortFunc(times, time.Time.Compare)
>>
>> It's totally unclear to me how Time.Compare matches the compare func(a,b 
>> T) int signature? I assume it's something from the golang spec, but which 
>> part?
>>
>> Are there other typical uses of this capability that are common?
>>
>> 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 visit 
https://groups.google.com/d/msgid/golang-nuts/b8199569-d85d-4138-9465-3d32d2dbca3en%40googlegroups.com.