That's a really helpful comment. I'll give the embed/fs.FS approach a go --
thank you.
On 20/01/25, Sean Liao (s...@liao.dev) wrote:
> The playground, which also serves pkg.go.dev examples. runs in an
> isolated environment with just the built test/example binary, without
> the source code.
> Con
Hi there,
I would like to patch a package from the standard library in a large Go
project. To be specific, I'd like to replace archive/tar
in https://github.com/containers/podman.
I can kludge this by creating my own version of the tar package, and
patching up the imports across the vendor/ d
There was a lot of discussion of this on the proposal, starting with (and
well summarized by) https://go.dev/issue/61515#issuecomment-1646194700. If
we don't inline, there will be cases like yours that wanted to benchmark
with inlining but don't get it. If we do inline, there will be cases that
are
ok. Thanks Ian and Dan for your explanations even if I understand that the
reason is just an implementation reason which introduces a bias on
unpacking operator (seperation of concern would have be great here I
suppose but maybe less efficient).
Le lundi 20 janvier 2025 à 23:54:43 UTC+1, Dan Ko
Curious if the new runtime.Cleanup() would allow auto sync.Pool.Put() for a
variable. I'm not sure from the documentation if this would work or would
cause some type of issue (the variable was on its way to collection and
then gets put in a pool. I assume it would stop collection?). The
guar
Oh that's perfect! Pretty much what I was looking for. Let me test it and
get back to you.
I wonder where the blog author found that flag? It's not exposed in `go
test`
On Tuesday, January 14, 2025 at 5:27:07 AM UTC-8 Byungjun You wrote:
> Have you try go test with -args -test.gocoverdir param
On Tue, Jan 21, 2025 at 6:10 PM John wrote:
>
> Curious if the new runtime.Cleanup() would allow auto sync.Pool.Put() for a
> variable. I'm not sure from the documentation if this would work or would
> cause some type of issue (the variable was on its way to collection and then
> gets put in a
Thanks Dan.
Also I was mixing up "comparable" and "actually being equal", as in ==
returning true.
I think comparable just means "will compile without error".
On Wednesday, January 22, 2025 at 7:10:10 AM UTC Dan Kortschak wrote:
> On Tue, 2025-01-21 at 23:00 -0800, Jason E. Aten wrote:
> >
> >
On Tue, 2025-01-21 at 23:13 -0800, Jason E. Aten wrote:
> I think comparable just means "will compile without error".
Yes, this is the case.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails
Reading https://go.dev/ref/spec#Comparison_operators , I
come across the interesting but a little ambiguous definition
of equality of channels:
*"Channel types are comparable. Two channel values areequal if they were
created by the same call to make orif both have value nil." (emphasis mine)*
On Tue, 2025-01-21 at 23:00 -0800, Jason E. Aten wrote:
>
> So what is "the same make"?
It's not the same make, it's the same *call* to make. So a := make(chan
struct{}); b := a; if a == b { /* this executes */ }.
--
You received this message because you are subscribed to the Google Groups
"go
11 matches
Mail list logo