Re: [go-nuts] convert *byte to []byte

On Fri, Dec 7, 2018 at 10:50 AM roger peppe wrote: > On Fri, 7 Dec 2018, 3:26 pm 'Bryan Mills' via golang-nuts < > golang-nuts@googlegroups.com wrote: > >> On Monday, December 3, 2018 at 12:02:07 AM UTC-5, Ian Lance Taylor wrote: >>> >>> On Sat, Dec 1, 2018 at 9:39 AM wrote: >>> > >>> > I am usi

[go-nuts] Re: Problems buildding go from source, tests "hangs"

What is the output of `$(go env CC) --version` on your machine?` On Wednesday, August 2, 2017 at 8:31:37 AM UTC-4, SauliusGurklys wrote: > > Hi, > > while building go from source: > > cd /usr/local/src/go > ./clean.bash > ./all.bash > > build succeeds without any problem and then when tests are st

Re: [go-nuts] Re: Mapping C pointer to BYTE to golang []byte

You haven't actually said which system call you're invoking, but from the name CERT_CONTEXT and the layout of the struct I'm guessing it's probably CertCreateCertificateContext or CertEnumCertificatesInStore

Re: [go-nuts] Re: Mapping C pointer to BYTE to golang []byte

You can ignore the vet warning if you are certain that the uintptr values you are converting to unsafe.Pointer are *valid pointers* (i.e., not non-pointer sentinel values) that point *outside the Go heap*. It sounds like that is probably the case, but you might want to check with someone more fami

Re: [go-nuts] Re: How to pass Go []byte (arrays/slices) as C *char to C functions

On Wed, Jan 24, 2018 at 3:00 PM, Christian LeMoussel wrote: > Thank you Bryan for your advice. > In examples, I see how to pass the Go pointers directly. > > For example : > h := C.CString(name) > defer C.free(unsafe.Pointer(h)) > gerrno, err := C.getaddrinfo(h, nil, &hints, &res) > T

Re: [go-nuts] Re: Struggling with go mod, micro-repos and private forks

On Thu, Oct 24, 2019 at 5:36 AM Shaun Crampton wrote: > I think the biggest problem we have is when working with private repos. >>> What I want to express to the tool is >>> >>> My module requires commit abcd1234 (or version v1.2.3) of dependency >>> x/y/z >>> >>> Look for any instances of depen

Re: [go-nuts] Re: Struggling with go mod, micro-repos and private forks

On Thu, Oct 24, 2019 at 1:07 PM Shaun Crampton wrote: > I circed some of the suggestions round my team. Sounds like others had > already tried some of the suggestions with mixed results: > > >- Go v1.13 still has trouble authenticating to github without an >"insteadof" in the config. We

Re: [go-nuts] Help with Go channels and select talk

I agree. It seems to me that the problem in example 2 is deep in the architecture of the program, not just a detail of the `select` statements. The `connect` function essentially functions as a single-worker “worker pool”, storing the data in a goroutine (specifically, in the closure of the `srv

Re: [go-nuts] Help with Go channels and select talk

On Thu, Dec 12, 2019 at 1:17 AM Egon Kocjan wrote: > My demo is based on a real problem in our code. The issue here is that I > cannot paste proprietary code and it's large and complex anyway. I > distilled the problem to a bidi-communication coding exercise. The "go srv" > in the real code is an

Re: [go-nuts] Publishing and using go module from tarball?

See also the golang.org/x/mod/zip package. On Monday, January 6, 2020 at 10:02:25 AM UTC-5, Amnon Baron Cohen wrote: > > > Go modules tooling does not seem to support http at > > all and as for the https I did not find any way to allow use of > self-sign

[go-nuts] Re: modules exclude version and above

Could you provide explicit steps (ideally a `go.mod` file and a corresponding `.go` source file, and the version of the Go toolchain you are using) to reproduce the problem? All three of those `v2` versions appear to have `go.mod` files, so the `go` command should not allow them to be used as `

Re: [go-nuts] Re: modules exclude version and above

Ok, I think I've figured out what's going on. The commits tagged `v2.0.2` and `v2.0.3` in this repo have a module in subdirectory `v2` that declares its path to be ` github.com/nicksnyder/go-i18n/v2` . However, that module cannot match the requested path ` g

[go-nuts] Re: No "official" documentation suggest to use annotated tags for releasing a new module version

Please file an issue to update the documentation. (https://golang.org/issue/new) On Wednesday, January 15, 2020 at 11:46:41 AM UTC-5 Manlio Perillo wrote: > Today I release my first release of a module. > > Following https://blog.golang.org/publishing-go-modules, I create a non > annotated tag.

[go-nuts] Re: go mod vendor command leads to LF will be replaced by CRLF warning

`go mod vendor` copies in the files as found in the repository. It does not normalize them according to your local .gitattributes. (In fact, the `go` command intentionally ignores attribute-based transformations when downloading modules: see https://golang.org/issue/27153.) On Friday, January

[go-nuts] Re: Go 1.14: how to -linkshared to a library produced by -buildmode=shared?

Did this work in 1.13? https://golang.org/issue/35759 is probably related; see especially the TODO here . Please file an issue so we don't lose

[go-nuts] Re: Where is the version number for a golang module declared?

On Tuesday, March 10, 2020 at 5:47:45 PM UTC-4 dean.w@gmail.com wrote: > This blog entry uses git > tags. It didn't mention branches. Are tags the only way to declare a > version number? > Yes, tags are the way to declare a version. Generall

Re: [go-nuts] Re: Where is the version number for a golang module declared?

`go install` does the same thing that it always has: it installs compiled binaries and object files, not module source code. (A module may contain multiple packages and multiple binaries.) See https://blog.golang.org/using-go-modules for a higher-level introduction, and note that https://golang.or

[go-nuts] Using modules with private repos

The protocol described in https://golang.org/cmd/go/#hdr-Remote_import_paths allows you to serve any repo URL for any import path that begins with your server's domain name. You can use basic auth with such a server via credentials stored in a .netrc file, which also works with git. -- You re

[go-nuts] random test failure of TestScript/mod_indirect in 'cmd/go'

Please file an issue. https://golang.org/issue/new -- 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 discuss

[go-nuts] Re: Right way to convert c char to golang bytes

Note that in general C strings are not restricted to 2³¹ bytes on 64-bit systems. (Larger strings are unusual, but fairly trivial to construct.) So I would recommend avoiding hard-coded array types of any size. You say that C.GoBytes truncates at zero. However, that does not reproduce for me. Ar

Re: [go-nuts] Re: [generics] Type lists should be usable in any interface

On Wednesday, June 17, 2020 at 12:08:59 AM UTC-4 Ian Lance Taylor wrote: > On Tue, Jun 16, 2020 at 9:04 PM Xie Zhenye wrote: > > > > I agree. constraint is different from normal interface. It's better to > use type SomeConstraint constraint {} than type SomeConstraint interface {} > > That is

Re: [go-nuts] [generics] why struct fields-based constraints were banned?

I could imagine a new kind of interface type specifying fields (not just methods), with the offsets of the corresponding fields in the concrete type stored in the interface's type descriptor. (I think such a feature would be orthogonal to the current design draft, and could be proposed separate

Re: [go-nuts] [generics] some questions

On Thursday, June 18, 2020 at 7:20:38 AM UTC-4 tapi...@gmail.com wrote: > On Thursday, June 18, 2020 at 5:53:28 AM UTC-4, Axel Wagner wrote: >> >> On Thu, Jun 18, 2020, 11:28 T L wrote: >> >>> How to declare a generic functions which converting a slice with type Ta >>> to a slice with type Tb. L

Re: [go-nuts] [generics] the empty type list

An empty intersection of type lists cannot be instantiated with any actual type, but if type-list interfaces could eventually be used as run-time types (as suggested in https://golang.org/design/go2draft-type-parameters#type-lists-in-interface-types), then the interface with an empty type-list

[go-nuts] Re: [generics] Closure?

I think this is a bug in the parser, related to (but not the same as) https://golang.org/design/go2draft-type-parameters#instantiating-types-in-type-literals . Adding doubled parentheses seems to make it work (https://go2goplay.golang.org/p/JSQ_8kGOC_A), but the `Format` button doesn't preserve

Re: [go-nuts] [generics] Closure?

Ah, this is https://golang.org/issue/39654. On Thursday, June 18, 2020 at 2:43:48 PM UTC-4 frave...@gmail.com wrote: > I think this probably gets a little closer to what you were going for, but > there's a puzzling error that leads me to think the parser doesn't quite > understand the instantia

Re: [go-nuts] [generics] the empty type list

On Thu, Jun 18, 2020 at 4:19 PM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Addendum: In Go, every type needs to be inhabited by at least one value - > it's zero value. And we already have a type that can take *exactly* one > value, namely struct{}. > That is true, but

Re: [go-nuts] Re: [generics] Type lists should be usable in any interface

On Fri, Jun 19, 2020 at 1:30 AM Ian Lance Taylor wrote: > On Wed, Jun 17, 2020 at 7:58 PM 'Bryan C. Mills' via golang-nuts > wrote: > > > > On Wednesday, June 17, 2020 at 12:08:59 AM UTC-4 Ian Lance Taylor wrote: > >> > >> On Tue, Jun 16, 2020 at 9:

Re: [go-nuts] Re: [generics] Type lists should be usable in any interface

On Fri, Jun 19, 2020 at 2:38 PM Ian Lance Taylor wrote: > On Fri, Jun 19, 2020 at 9:31 AM Bryan C. Mills wrote: > > > > On Fri, Jun 19, 2020 at 1:30 AM Ian Lance Taylor > wrote: > >> > >> This code is acting as though, if ordinary interface types could have > >> type lists, it would be OK to wr

Re: [go-nuts] Re: [generics] Type lists should be usable in any interface

On Sat, Jun 20, 2020 at 5:25 PM Ian Lance Taylor wrote: > On Fri, Jun 19, 2020 at 1:50 PM Bryan C. Mills wrote: > > > > On Fri, Jun 19, 2020 at 2:38 PM Ian Lance Taylor > wrote: > >> > >> On Fri, Jun 19, 2020 at 9:31 AM Bryan C. Mills > wrote: > >> > > >> > On Fri, Jun 19, 2020 at 1:30 AM Ian

[go-nuts] [generics] pointer methods vs. stronger type inference

This evening I was thinking about the parts of the Type Parameters draft design that are not interface types per se, and I went back over the section on pointer methods . It struck me as odd, because the second example (described

[go-nuts] [generics] constraint for nillable types?

I tried writing a generic “FirstNonNil” function, but got stuck at the "== nil" part. First I thought to maybe add a type list enumerating all of the nillable types, but I don't have a way to enumerate all of the possible interface types as part of that list, and there is no constraint for “any in

Re: [go-nuts] Re: [generics] Type lists should be usable in any interface

My brain was stuck on subtyping yesterday, and when I thought about how subtyping relates to type-list interfaces I realized that they could be made more orthogonal — and more like existing interface types, more useful as sum types, and perhaps even more amenable to specialization via type-switches

Re: [go-nuts] mytex.RWLock recursive read lock

Note that a lock on a sync.Mutex or sync.RWMutex is *not* held by a specific goroutine: it can be locked by one goroutine, then communicated by some other means (such as being sent on a channel) and unlocked on a *different* goroutine. (See also https://golang.org/issue/9201.) That is: these lo

Re: [go-nuts] mytex.RWLock recursive read lock

nic? The behavior is well-defined and documented. (Admittedly the documentation is a bit awkward, but documentation is hard to get exactly right.) On Tue, Sep 22, 2020 at 3:56 PM 'Bryan C. Mills' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >> Note that a lo

Re: [go-nuts] Re: Proper way of mocking interfaces in unit tests - the golang way

I think that FAQ entry really *is* referring to jUnit-style assert functions, including those provided by testify. The core of the problem is that `assert` functions generally *cannot* provide enough context to produce useful test failures

[go-nuts] Re: Proper way of mocking interfaces in unit tests - the golang way

As for mocking dependencies: in my experience, the best strategy is often not to. It is a good idea to avoid depending on services or resources external to the test, such as other production services. However, in my experience you'll get much better test fidelity — you'll find more real bugs, a

[go-nuts] Re: Question about "go get", modules and indirect dependencies

`go mod download` should include `.info` files for the requested module(s), or for all dependencies of your module (if you don't give any specific modules as arguments). That said, .info files are not particularly useful in general, and the `go` command should probably read them less than in do

Re: [go-nuts] Re: Question about "go get", modules and indirect dependencies

Yeah, that's exactly https://golang.org/issue/42723. `go list` shouldn't need to read those files. In the meantime, you could try `go list all` and/or `go mod tidy` after your `go get`..? On Wed, Jan 6, 2021 at 1:27 PM Orson Cart wrote: > Thanks for the advice Bryan. > > Sadly I tried using go

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 8 updates in 4 topics

50ns is approximately the cost of a cross-CPU L2 cache miss. Any time you have tight cross-CPU communication, you're going to incur that cost no matter how the communication is performed — whether it's via a sync.Mutex, a channel, or an atomic write. The way to eliminate that cost is to elimina

[go-nuts] Re: Module dependency cycles

In general the way to cut cycles is to cut a set of versions of the affected modules such that each module in the set requires only the other versions in that set. (So, a new `thanos` v0.19.0, a new `cortex` v1.8.0, and a new `alertmanager` v0.22.0, I think?) The trick is to publish all of them

Re: [go-nuts] Re: Module dependency cycles

On Thu, Feb 25, 2021 at 7:43 PM Bart Grantham wrote: > If I understand the post here, it seems we're also struggling with this > issue with our private repos. For us it means that in the go.sum of the > highest level repos there's references for everything, all the way back to > the initial v0.0

Re: [go-nuts] Modules and internal packages

You should be able to use a `replace` directive to replace the full path "github.com/Michael-F-Ellis/skeleton/internal/common" or similar. If you take that approach, the skeleton module itself *must not* contain that package, or else the `import` statements that refer to that package would be a

Re: [go-nuts] Modules and internal packages

tand what this even means. You're saying that you have some API for constructing a paired server component and WASM client, and the way that projects use that API is by swapping in their own "internal/common" package. That *already* fundamentally breaks the concept of “internal”

Re: [go-nuts] Case for Cond.WaitTimeout()

For what it's worth, I would argue that the 1-buffered channel pattern in Go *is* “basic concurrent programming”. 1-buffered channels are used as basic building blocks throughout the standard library — consider time.Ticker or signal.Notify — and for good reason. A 1-buffered channel is a very s

[go-nuts] Re: go mod vendor without updating packages

Module dependencies are transitive. 'go mod edit' edits the syntax of the go.mod file, but does not ensure that the resulting transitive dependencies are consistent. To adjust your dependencies, use 'go get -d' instead of 'go mod edit': go get -d google.golang.org/grpc@v1.29.1 That will downgra

Re: [go-nuts] proposal: infer module name via version control when running `go mod init`

go mod init should only infer a module path when it can be certain that path is correct. For packages already stored in GOPATH/src, it knows the correct path with high confidence: the path relative to GOPATH/src is the path by which the packages in the module are imported when in GOPATH mode, s

[go-nuts] Re: proposal: ignore stale information in go list -find -json

https://golang.org/issue/29666 (still open) is the general issue for avoiding unnecessary work in 'go list'. It isn't obvious to me which kind of stale information we can omit for 'go list -find' in particular. On Wednesday, May 12, 2021 at 4:11:14 AM UTC-4 manlio@gmail.com wrote: > The go

[go-nuts] Re: Go's compatiblity with non-module repositories

The go get command ensures that all packages transitively imported by the named package(s) are provided by some module in the module dependency graph. The go mod tidy subcommand does the same for all packages transitiv

Re: [go-nuts] Warning for look alike Unicode characters

See also: https://golang.org/issue/20115 (proposal: cmd/vet: detect homograph attacks) https://golang.org/issue/20209 (proposal: spec: disallow LTR/RTL characters in string literals?) https://golang.org/issue/20210 (proposal: spec: disallow unicode import paths to avoid punycode attacks) On Mond

Re: [go-nuts] unsafe string to []byte

For what it's worth, my unsafeslice.OfString makes a best effort to detect mutations of the sort that would occur when a Write implementation violates the io.Writer contract. It allows for vary levels of safety. Under `-race` it

Re: [go-nuts] Managing perpetually running goroutines

For the specific case of managing long-running polling- or pubsub-based tasks, I would suggest basically the same pattern that others on the thread have already given: use a `sync.Map` to associate each task ID with a small struct containing a `context.CancelFunc` and a channel that can be used

Re: [go-nuts] Managing perpetually running goroutines

On Wed, Sep 1, 2021 at 5:55 PM wrote: > Thanks Bryan, especially for the code example. > > > Would using a sync.WaitGroup in place of the `done` channel in your > example be overkill? Just exploring what’s possible here for my own > education. > Using a `sync.WaitGroup` in place of the `done` ch

[go-nuts] Re: Command `go test` without build constraints does not work

I think the distinction between "unit" and "integration" tests may be a red herring. As a user running tests, generally I want to be able to run “fast” or “smoke” tests (for quick iteration) vs. “slow” or “intensive” tests (to check for regressions and larger-scale statistical properties, and pe

[go-nuts] Re: Intentionally omitting requires in go.mod - alternative to multi-module repository?

On Thursday, January 13, 2022 at 12:45:13 PM UTC-5 rhcar...@gmail.com wrote: > Hello fellow Gophers! > > I help maintain an SDK module > that includes > packages that provide middleware to different web frameworks (e.g. echo >

[go-nuts] Re: Intentionally omitting requires in go.mod - alternative to multi-module repository?

On Monday, January 31, 2022 at 1:22:09 AM UTC-5 leig...@gmail.com wrote: > I'm a user of the sentry-go SDK who has been impacted by the large number > of dependencies in the past. > > >Independently, if your users have automated tools that are issuing > false-positive CVE warnings based on the m

[go-nuts] Re: go mod tidy doesn't rewrite go.mod file (shows go: warning "all" matched no packages)

Do you have a go.work file? If so, does it include the module in that directory? (Compare https://go.dev/issue/51604.) What do `go env GOMOD` and `go env GOWORK` report? On Friday, April 1, 2022 at 10:05:57 AM UTC-4 vaastav...@gmail.com wrote: > There is definitely source code in that folder. T

Re: [go-nuts] Re: Replacement for net.Error.Temporary in server Accept loops

Even ENFILE and EMFILE are not necessarily blindly retriable: if the process has run out of files, it may be because they have leaked (for example, they may be reachable from deadlocked goroutines). If that is the case, it is arguably better for the program to fail with a useful error than to ke

[go-nuts] Re: CertPool->SystemCertPool - API Behavior of Windows

Go 1.18 uses the Windows platform APIs to verify certificates (as proposed in https://go.dev/issue/46287). The specific changes are summarized in https://go.dev/doc/go1.18#crypto/x509. On Sunday, May 15, 2022 at 6:01:55 PM UTC-4 sre.ag...@gmail.com wrote: > Hi All, > > I am trying to use X509

[go-nuts] Re: how to organise code with channels and error handling?

On Friday, September 23, 2022 at 10:24:36 AM UTC-4 joche...@gmail.com wrote: > Dear all, > > I am writing a program which processes data in stages. To structure the > code cleanly, I would like implement each stage as an individual function > and use channels to pass data between stages. > I w

Re: [go-nuts] Integration testing program that internally forks itself

Generally I use environment variables for that sort of test, so that the part of the program that constructs the arguments for the program doesn't have to know to pass a special additional argument. (See, for example, https://cs.opensource.google/go/go/+/master:src/cmd/cover/cover_test.go;l=75

[go-nuts] Re: RLIM_INFINITY for loong64 has a special type.

POSIX specifies that RLIM_INFINITY in C has type rlim_t and that type rlim_t is an “unsigned integral type”, so the `uint64` value seems appropriate. (https://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/resource.h.html) And it appears that syscall.RLIM_INFINITY has the correct (unsigned

Re: [go-nuts] Re: [windows] c:= exec.CommandContext(ctx, ...) + c.Output() don't return when process is killed upon context expiration until child termination

On Friday, February 4, 2022 at 6:23:45 PM UTC-5 Pablo Caballero wrote: Hi Ian! Thank you so much for sharing that link with me. It was very enriching to read it. As I commented in my first message, the fact that the problem did not occur on Mac got me a bit confused at first. macOS does not h

[go-nuts] Re: Go called by C: is the goroutine locked to a thread?

If a C thread calls into Go, the goroutine processing that call (and only that goroutine) will run on the C thread. The Go runtime will initialize any of its own per-thread state for that thread as needed. If a goroutine calls into C, and that C thread calls back into Go, I believe that the C-t

Re: [go-nuts] Re: Go called by C: is the goroutine locked to a thread?

On Wed, Oct 25, 2023 at 9:58 AM Domenico Andreoli < domenico.andre...@linux.com> wrote: > On Tue, Oct 24, 2023 at 09:58:22AM -0700, 'Bryan C. Mills' via golang-nuts > wrote: > > If a C thread calls into Go, the goroutine processing that call (and > only > &

[go-nuts] Re: Why does my time.Ticker work fine for 6 months then suddenly stop sending ticks?

Given the number of known overflows present in the `time` package (https://go.dev/issue/20678, https://go.dev/issue/56909), I wouldn't be terribly surprised to find one in Ticker as well, although 6 months seems awfully short to hit an overflow bug. Consider filing an issue at https://go.dev/is

[go-nuts] Re: Changing PWD ruins test caching

As far as I can tell the code in question is only built on AIX and OpenBSD — are you using one of those two platforms? If not, perhaps the caching problem is coming from somewhere else. That said, it does appear that calls to `os.Chdir` result in a spurious dependency on the PWD variable: https:

Re: [go-nuts] How could we emulate condition variables using Go channels only?

Perhaps something like this: https://go.dev/play/p/wllkgRAtd4a Disclaimer: not yet tested, probably contains bugs. Also, I strongly _disrecommend_ the use of condition variables, because they're too bug-prone. 🙃 On Friday, January 12, 2024 at 2:48:09 PM UTC-5 Rochus Keller wrote: > > Something

Re: [go-nuts] How could we emulate condition variables using Go channels only?

Now with tests (copied from https://cs.opensource.google/go/go/+/master:src/sync/cond_test.go;drc=4a3071696ddfb13e1a8f35f76197b7b3143492f4): https://go.dev/play/p/BpLBYsSSqn2?v=gotip On Wednesday, January 17, 2024 at 5:38:18 PM UTC-5 Bryan C. Mills wrote: > Perhaps something like this: > https:

[go-nuts] Re: go mod download fails on docker for 1.20 (but not for 1.18)

In https://go.dev/issue/52545 we saw failures in the cmd/go tests on Google Cloud VMs due to a combination of a small number of available NAT ports and port exhaustion from TIME_WAIT connections, but the failure mode there was different (timed-out git commands rather than "cannot assign requeste

Re: [go-nuts] GO111MODULE=off go get deprecated?

Per https://go.dev/doc/go1.22#go-command: > go get is no longer supported outside of a module in the legacy GOPATH mode (that is, with GO111MODULE=off). Other build commands, such as go build and go test, will continue to work indefinitely for legacy GOPATH programs. This was discussed in https:

Re: [go-nuts] GO111MODULE=off go get deprecated?

On Mon, Mar 4, 2024 at 8:52 PM Jeffery Carr wrote: > On Monday, March 4, 2024 at 8:44:14 AM UTC-6 Bryan C. Mills wrote: > > Per https://go.dev/doc/go1.22#go-command: > > go get is no longer supported outside of a module in the legacy GOPATH mode > (that is, with GO111MODULE=off). Other build comm