[go-nuts] Re: slog formatter funcs? (e.g. slog.Infof)

I personally am a fan of formatted logs, but we didn't see a way to combine them with key-value pairs (you only get one variadic arg per function call). It wouldn't be hard to write a layer that wraps a slog.Logger or slog.Handler with xxxf functions. That's what I recommend. On Friday, December

[go-nuts] Re: possible bug in slog.Value json marshaling

Hi Steve, I'm not sure what the right answer is. Can you file this as a bug on go.dev/issues? On Thursday, September 7, 2023 at 2:30:09 PM UTC-4 Steven Pelley wrote: > Hi everyone, > > Possibly a bug or potential improvement in slog. > This will sound excessively complicated, which I recognize a

[go-nuts] [ANN] type-safe templates

The latest version of github.com/jba/templatecheck[0] supports templates that cannot have type errors at execution time. Once you've parsed your template `t` and all associated templates, call ct, err := templatecheck.NewChecked[MyData](t) If err == nil, then ct is a CheckedTemplate[MyData].

[go-nuts] Re: slog's use of runtime.Callers() with a skip

The Go runtime does the right thing. On Friday, August 11, 2023 at 8:58:53 AM UTC-4 jake...@gmail.com wrote: > As far as I can tell, skip works even in the face of inlined functions, at > least when used with runtime.CallersFrames(). It would be surprising to me > if it did not. Do you have an

Re: [go-nuts] What happened to sep in errorrs.join

I think you can do what you want with `HandlerOptions.ReplaceAttr`. It is given every attribute, even the message. It can't change the group names, though, and those can have newlines. On Tuesday, August 8, 2023 at 5:47:38 PM UTC-4 Ian Lance Taylor wrote: > [ + jba ] > > On Tue, Aug 8, 2023 at

Re: [go-nuts] Re: Types like http.Request and slog.LogValuer

On Saturday, July 29, 2023 at 12:18:53 PM UTC+2 Jonathan Amsterdam wrote: > >> I would write a type that wraps the request and implements LogValuer. >> Then you would log the request as >> >> logger.Debug("req", "r", requestWrapper{r}) >>

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

We don't plan on exposing the commonLogger implementation, but you can write your own handler to get the exact format you want. See github.com/jba/slog/handlers for some existing code. See https://github.com/golang/example/tree/master/slog-handler-guide for a guide to writing a slog handler. On

[go-nuts] Re: Types like http.Request and slog.LogValuer

I would write a type that wraps the request and implements LogValuer. Then you would log the request as logger.Debug("req", "r", requestWrapper{r}) On Thursday, July 27, 2023 at 10:01:27 AM UTC-4 Jens-Uwe Mager wrote: > I am trying to convert some older code to slog and I am running into t

[go-nuts] call for data on HTTP routing

At https://github.com/golang/go/discussions/60227, we're discussing enhancements to the standard library's http.ServeMux routing. Two issues have arisen that we could use your help on. The first is easy to state: does fast routing matter? Are there Go web servers for which http.ServeMux is too

[go-nuts] structured, leveled logging

If you're interested in logging, you may want to check out the discussion about a potential new standard library package for structured logging. https://github.com/golang/go/discussions/54763 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] Finding error type for `errors.As` and `errors.Is`

You can write such a function yourself. For that reason and since it would be rarely useful, I don't think it's likely to become part of the standard library. On Thursday, April 1, 2021 at 9:02:34 AM UTC-4 Michael Schaller wrote: > Roger, I think you slightly misunderstood me. ;-) > > It is tru

Re: [go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go

I changed the encoding so that the previous generated code is no longer necessary. Encoded data now carries all the information needed to decode struct fields correctly, even if fields have been added and reordered. On Sunday, January 24, 2021 at 8:29:58 AM UTC-5 Jonathan Amsterdam wrote

Re: [go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go

Thanks for the suggestions. I created https://github.com/jba/codec/pull/1 to address them. You can comment in more detail there if you'd like. On Wed, Jan 20, 2021 at 12:13 PM roger peppe wrote: > On Wed, 20 Jan 2021 at 13:31, Jonathan Amsterdam > wrote: > >> The encoding

Re: [go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go

erface values, > etc? is the schema implicit or sent on the wire?) > cheers, > rog. > > On Tue, 19 Jan 2021 at 14:59, Jonathan Amsterdam > wrote: > >> Uses code generation for fast encoding and decoding of Go values to >> bytes. Handles sharing and cycles too.

[go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go

Uses code generation for fast encoding and decoding of Go values to bytes. Handles sharing and cycles too. https://pkg.go.dev/github.com/jba/codec -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receivin

[go-nuts] [ANN] templatecheck: type-checking Go templates

The github.com/jba/templatecheck package[0] can validate field references and other operations of a text/template or html/template in tests or during program startup. It also works for github.com/google/safehtml/template[1]. [0] https://pkg.go.dev/github.com/jba/templatecheck [1] https://pkg.go

[go-nuts] Re: decode unknown CBOR type with set of known types

My first question would be, is the type encoded into the CBOR blob somehow? Like by a tag? If structs are encoded as maps, with no type information, then the input doesn't have enough information to do what you want. How could the blob (using JSON notation) {"X": 1, "Y": 2} know whether i

Re: [go-nuts] godoc.org pkg.go.dev banner feedback

Fixed in production. The links work now. On Monday, July 6, 2020 at 12:47:34 PM UTC-4 Julie Qiu wrote: > Thanks for letting us know! This looks like a bug - we'll look into it. I > filed an issue here: https://github.com/golang/go/issues/40071 > > > On Thursday, July 2, 2020 at 12:00:57 PM UTC-4

[go-nuts] Re: go.pkg.dev missing golang packages

You can open an issue on the Go issue tracker. Use this link: https://golang.org/s/discovery-feedback. I filed https://golang.org/issue/39894. On Saturday, June 27, 2020 at 1:20:15 PM UTC-4, Steve Roth wrote: > > I understand that some Go package documentation is not documented on > go.pkg.dev

Re: [go-nuts] Using context package for goroutines cancellation is quite verbose

Typically, a network communication system, like gRPC for example, will accept contexts for network calls and turn context done-ness into an error. The typical signature of an RPC-backed function is func(context.Context, req *Request) (*Response, error) If the context times out or is cancell

Re: [go-nuts] A simplified generics constraint system.

On Friday, September 14, 2018 at 8:06:31 PM UTC-4, alanfo wrote: > > Thanks for your comments, Jonathan. > > I did in fact deal with all the cases you mention in my 'fuller' proposal: > > https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251 > > where I'd used a device to restrict the b

Re: [go-nuts] A simplified generics constraint system.

I'm sympathetic to the general idea, but I don't think this quite does it. In addition to introducing a bunch of new names, it's not expressive enough: - You can't express "string or []byte", as you note. There are many algorithms where this would be useful. See the strings and bytes packages f

[go-nuts] Re: Go 2 error-handling counter-proposal: returnfrom

What's the meaning of this code? func main() { f := g() f() } func g() func() { Top: return func() { returnfrom Top, nil} } On Thursday, September 13, 2018 at 3:29:03 PM UTC-4, Scott Pakin wrote: > > I recently added to the Go 2 Error Handling Feedback > <

Re: [go-nuts] Scrapping contracts (was: "Generics as bultin typeclasses")

Not to be snide, but we are looking for examples, not kinds of examples. Do you know of actual code where this would benefit? For example, could field accessors improve the standard image and image/color packages? On Wednesday, September 12, 2018 at 9:15:24 AM UTC-4, Mandolyte wrote: > > On fi

Re: [go-nuts] Re: Generics as builtin typeclasses

On Tuesday, September 11, 2018 at 9:24:56 AM UTC-4, Larry Clapp wrote: > > This question frankly struck me odd, given the context. To paraphrase: > "Do I have examples of where accessing a field in a generic struct type > might be useful?" I kind of assumed that, hip-deep as we are in a > di

[go-nuts] Re: Scrapping contracts (was: "Generics as bultin typeclasses")

> > * I think constraining type-parameters to channel/slice/map types might > not be needed at all. Instead of, say "func Foo(type T channelOfBar) (ch > T)", ISTM that we can use "func Foo(ch chan Bar)". Since any channel-type > with element type Bar can be assigned to `chan Bar`, this would al

Re: [go-nuts] Re: Generics as builtin typeclasses

id sanity-check against > the examples in the contract design doc, but I have not put enough thought > into it that there might not be a couple nooks and crannies I haven't > thought of, as you've proven before :) ) > > On Tue, Sep 11, 2018 at 1:21 AM Jonathan Amster

Re: [go-nuts] Re: Generics as builtin typeclasses

on: If we can express the vast majority (or >> even all) of the needed contracts as combinations of this handful of >> base-cases, why would we need to allow the full power of Go syntax, which >> enables to write all the less than obvious ones too? >> >> (to

Re: [go-nuts] Re: Generics as builtin typeclasses

On Monday, September 10, 2018 at 4:17:57 PM UTC-4, Axel Wagner wrote: > > On Mon, Sep 10, 2018 at 8:57 PM Jonathan Amsterdam > wrote: > >> FWIW, I think Ian's criticism of not wanting a list of new identifiers to >>> express operator constraints is fair. It

Re: [go-nuts] Re: Generics as builtin typeclasses

I'm wrong about `==` here, because it's defined for interface values. `comparable` could be an interface. But it won't work for other operators like `<` or `+`. On Sunday, September 9, 2018 at 2:49:26 PM UTC-4, Jonathan Amsterdam wrote: > > FWIW, in my pseudo-interfac

[go-nuts] Re: Link: Getting specific about generics

Sorry, I'm wrong about `eq`. It could be an interface, because `==` is treated specially for interface types. But you couldn't have an interface for any other operator, like `<` or `+`. On Monday, September 10, 2018 at 9:55:04 AM UTC-4, Jonathan Amsterdam wrote: > > From the

Re: [go-nuts] Re: Generics as builtin typeclasses

t;> specify those. I specifically don't allow that and that's the whole point >>> I'm making. So this doesn't seem like a particularly nice way to have a >>> discussion. >>> >>> But yes, if it makes you happier, we can call them "

[go-nuts] Re: Link: Getting specific about generics

> > > The problem is that the spec says that the operands of == have to be the > same type > Correction: one operand must be assignable to the type of the other. The example still stands: you can't compare an int and a float64. -- You received this message because you are subscribed to the

[go-nuts] Re: Link: Getting specific about generics

>From the blog post: For example there could be an eq interface that’s equivalent to a contract > with an x == x. Actually, there can't. If eq were an interface, then func f(x, y eq) bool { return x == y } would be legal. And so would the call var a int var b float64 f(a,

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sunday, September 9, 2018 at 3:52:24 AM UTC-4, Ian Lance Taylor wrote: > > On Sat, Sep 8, 2018 at 7:53 PM, Jonathan Amsterdam > > wrote: > >> When is it important to not just express what operations are > >> required for a type, but also to try to rule ou

Re: [go-nuts] Re: Generics as builtin typeclasses

t; "type-checking function body" idea and instead define a set of > base-contracts you can use for operators) and you'd end up with pretty much > my design. > > On Sun, Sep 9, 2018 at 11:17 PM Jonathan Amsterdam > wrote: > >> >> >> On Sunday,

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sunday, September 9, 2018 at 3:19:16 PM UTC-4, Axel Wagner wrote: > > On Sun, Sep 9, 2018 at 8:49 PM Jonathan Amsterdam > wrote: > >> The problem is that this program seems to type-check, but it is invalid. >> The == operator is specified to work on operands of the

Re: [go-nuts] Re: Generics as builtin typeclasses

, G Graph(Node, Edge)) (g G, from, to Node) []Edge except according to your description, all three type parameters would have Graph(Node, Edge) as constraints, which doesn't make sense either. > On Sun, Sep 9, 2018 at 8:21 PM Jonathan Amsterdam > wrote: > >> >

Re: [go-nuts] Re: Generics as builtin typeclasses

On Saturday, September 8, 2018 at 11:58:46 PM UTC-4, Robert Engels wrote: > > For the math operator, since Go already doesn’t do automatic numeric > conversions, all of the operators are almost trivially implemented as > methods, e.g. operator + is > > pseudo generic interface - not really req

Re: [go-nuts] Re: Generics as builtin typeclasses

> > FWIW, in my pseudo-interface description > ... > You mention that comparable is a pseudo-interface, which means the type supports the == and != operators. You say that comparable and the other pseudo-interfaces are types. So I

Re: [go-nuts] Re: Generics as builtin typeclasses

> > > FWIW, in my pseudo-interface description > , > Unrelated to this particular issue, but since you link to your blog post, I just want to mention that in your graph example, func ShortestPath(type Node, Edge) (g Graph(Node,

Re: [go-nuts] Re: Generics as builtin typeclasses

I don't think Go will add operator overloading, even if it simplifies generics. Go has a core principle that doesn't get written down very much: syntax is hard-coded. If you see a piece of syntax in Go, it will never execute user code. (The obvious exception, of course, is a function call.) Thi

Re: [go-nuts] Re: Generics as builtin typeclasses

> > When is it important to not just express what operations are > required for a type, but also to try to rule out some types? > I think the short answer is: numeric code. That's when one thinks about which types make sense for an algorithm, not just which operations. I'm not exactly sure w

[go-nuts] confused about assignability

Consider type Int int var y int = Int(3) The spec says A value x is assignable to a variable of type T ("x is assignable to T") if one of the following conditions applies: - x's type V and T have identical underlying types

[go-nuts] methods for error

Inspired by Rob Pike's recent blog post and Dave Cheney's errors package , I wrote down some methods that I think all errors should implement. The key idea is that an error only needs to

[go-nuts] using GitHub Pages for import paths

What do you all think about using GitHub Pages URLs for import paths? I got to thinking about that because Go is moving towards having real dependency management, and it looks like the repo is going to be the unit of versioning. That implies that repo boundaries are going to be changing a lot in t

[go-nuts] [ANN] upcoming changes for cloud (not appengine) clients

If you use a package whose import path starts with "google.golang.org/cloud", please see the important announcement at google-api-go-announce . -- You received this message because you are subscribed to the Google Groups "golang-nut

[go-nuts] [ANN] new mailing list for Google APIs with Go

If you use Go to access Google APIs (for example, by using the Google Cloud API clients at import paths starting with "google.golang.org/cloud"), we recommend you join the new group google-api-go-announce . We at Google will use that l