gorrila/websocket is a very mature library. The current maintainer stepping
down doesn't change that.
I wouldn't avoid it. The very fact that its been so stable and successful
for so long that there's
nothing left to do on it is actually a recommendation.
Nice tutorial:
Thanks, folks! I just upgraded my app to the 119 runtime too, and it went
very smoothly!
On Mon, Dec 19, 2022 at 11:40 AM 'drc...@google.com' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> I just checked with my personal app engine project ("gcloud app deploy",
> that's app engine, I
> By stdlib, you presumably mean the x/net/websocket package,
Careful with this library, it's not quite correct. Websocket is
a frame-oriented protocol, while x/net/websocket implements a simplistic
API that does not always preserve frame boundaries.
Correct implementations include:
Q1: stack frames are rounded to a multiple of 8 bytes, to keep the stack
pointer 8-byte aligned. Part of that is rounding argsize to 8 bytes. (It's
not strictly necessary, and we could report 4, I think, if there are no
return values.)
Q2: I think 4 are from rounding argsize up to 8 bytes, and
On Mon, Dec 19, 2022 at 8:31 PM Red Daly wrote:
> Methods cannot take type arguments, so I find myself writing `func Foo(o
> Object) {...}` instead of `func (o Object) Foo()` in cases where Foo needs
> a type parameter.
>
> I would like some type of pseudo-method in Go similar to Kotlin's
>
The standard library itself doesn't do it, but it does provide you with
hooks to do so.
Set crypto/tls.Config.GetCertificate to an appropriate implementation of
OCSP stapling.
Examples of ocsp stapling can be found via the package discovery site:
https://pkg.go.dev/search?q=ocsp+staple
- sean
https://go.dev/issue/26460
- sean
On Mon, Dec 19, 2022 at 7:31 PM David M wrote:
> Not quite sure if this is a bug but it's annoying:
>
> If the example tested string contains a trailing space before a newline,
> the test always fails no matter how.
> // this test passes
> func
I tried to google this for a while now, and all I find regarding this topic
is: https://groups.google.com/g/golang-nuts/c/QC5FOysyVxg
This is already many years old, and to me it seems like there is code
inside Go which allows to perform server side OCSP stapling. However, I am
unable to find
Not quite sure if this is a bug but it's annoying:
If the example tested string contains a trailing space before a newline,
the test always fails no matter how.
// this test passes
func ExampleFormat() {
fmt.Println("a\nb")
// Output:
// a
// b
}
// this test fails no matter
package main
func main() {
var x int32 = 1
nop(x)
}
//go:noinline
func nop(x int32) {}
*Go version: go1.16.15 windows/amd64*
I wrote above code and compiled it into assembly with `go1.16.15 tool
compile -S -N -l main.go` for truly understanding Go functions call.
The following is the
Methods cannot take type arguments, so I find myself writing `func Foo(o
Object) {...}` instead of `func (o Object) Foo()` in cases where Foo needs
a type parameter.
I would like some type of pseudo-method in Go similar to Kotlin's extension
methods. Made up syntax:
```go
package foo
func (o
I just checked with my personal app engine project ("gcloud app deploy",
that's app engine, I think), and with 1.19 specified in go.mod and
"runtime: 119" in app.yaml, the app reported runtime.Version() of 1.19.3.
My understanding is this is a recent change.
On Thursday, December 15, 2022 at
It depends entirely on your application, and how the various goroutines are
wired together with channels.
But as a guiding principle: I'd say that anything which *sends* on a
channel should close it when it's finished - whether that be due to context
cancellation, or some other reason.
Hallöchen!
Brian Candler writes:
> On Monday, 19 December 2022 at 12:01:39 UTC Torsten Bronger wrote:
>
>> But would you agree that additional checking is necessary if
>> DoSomething does not have a ctx argument?
>
> Given that you're running DoSomething synchronously, it will always
> run to
On Monday, 19 December 2022 at 12:01:39 UTC Torsten Bronger wrote:
> But would you agree that additional checking is necessary if
> DoSomething does not have a ctx argument?
>
Given that you're running DoSomething synchronously, it will always run to
completion. So you'll always have a valid
Hallöchen!
Jan Mercl writes:
> [...]
>
> From https://go.dev/ref/spec#Select_statements
>
>
> 2. If one or more of the communications can proceed, a single one that
> can proceed is chosen via a uniform pseudo-random selection.
>
>
> Selecting the send case in the above code, when both
Hallöchen!
Harris, Andrew writes:
> The precise ordering of things is a bit non-deterministic at the
> fringe. If precise ordering really matters (maybe for cancelling a
> stream like this, it doesn’t, sometimes it does), a default case in
> the select statement is really useful, and it also
The precise ordering of things is a bit non-deterministic at the fringe. If
precise ordering really matters (maybe for cancelling a stream like this, it
doesn’t, sometimes it does), a default case in the select statement is really
useful, and it also matters what DoSomething does.
On Monday, 19 December 2022 at 10:01:41 UTC Torsten Bronger wrote:
> I would additionally check for ctx.Err() != nil somewhere in the
> loop. Or is there a reason why this is not necessary?
>
See https://pkg.go.dev/context#Context
// If Done is not yet closed, Err returns nil.
// If
On Mon, Dec 19, 2022 at 11:01 AM Torsten Bronger
wrote:
> The context documentation gives this example:
>
> // Stream generates values with DoSomething and sends them to out
> // until DoSomething returns an error or ctx.Done is closed.
> func Stream(ctx context.Context, out chan<-
Hallöchen!
The context documentation gives this example:
// Stream generates values with DoSomething and sends them to out
// until DoSomething returns an error or ctx.Done is closed.
func Stream(ctx context.Context, out chan<- Value) error {
for {
v, err :=
21 matches
Mail list logo
