For the archeologists, underlying issue has been acknowledged
https://github.com/golang/go/issues/67574; sadly, this forum kept schtumm.
On Monday, May 6, 2024 at 1:46:17 PM UTC+2 TheDiveO wrote:
> As I cannot edit the title anymore: it's about upgrading to the last
> version that can be used
As I cannot edit the title anymore: it's about upgrading to the last
version that can be used without toolchain change, which is not necessarily
the "latest" version of a dependency.
On Monday, May 6, 2024 at 10:42:17 AM UTC+2 TheDiveO wrote:
> FYI, go-mod-upgrade runs the following command
FYI, go-mod-upgrade runs the following command under its hood:
go list -u -mod=readonly -f '{{if (and (not (or .Main .Indirect))
.Update)}}{{.Path}}: {{.Version}} -> {{.Update.Version}}{{end}}' -m all
On Monday, May 6, 2024 at 10:36:08 AM UTC+2 TheDiveO wrote:
> Up front, I have to admit that
Up front, I have to admit that I'm struggling with the newly introduced
download-your-go-toolchain-on-the-fly when it comes to:
1. having reproducible builds in a CI/CD pipeline without getting
downloaded a different toolchain as installed at the stage start,
2. being a module
They are distinct indeed.
An "if sl == nil ..." will not match an empty slice. It is len(sl) that
returns 0 for both nil and empty slices, and range working along the same
idea.
playground example: https://goplay.tools/snippet/df0bG6YXfJZ
https://goplay.tools/snippet/df0bG6YXf
at 8:01:11 PM UTC+2 Ian Lance Taylor wrote:
> On Tue, Apr 2, 2024 at 2:35 AM 'TheDiveO' via golang-nuts
> wrote:
> >
> > On Linux, given an arbitrary binary executable with symbol information
> in the executable, how can I lookup an instruction pointer address to get
> the
On Linux, given an arbitrary binary executable with symbol information in
the executable, how can I lookup an instruction pointer address to get the
corresponding symbol name?
The binary (and its process) isn't a Go binary, but any arbitrary
executable. The stack unwinding has already been
Looking and looking again, at least I spotted a lonely "open
/tmp/go-build/covmeta: no such file or directory" error message.
This now finally matches https://github.com/golang/go/issues/65653 and
using gotip finally succeeds correctly.
--
You received this message because you are
Dear Gophers,
I'm struggling with "go test -coverpkg=XXX ... ./... -args
-test.gocoverdir" returning non-zero exit codes, albeit all tests are
passing. It might well be that I'm not really yet understanding how "go
test -coverpkg=" is supposed to work. As illustrated below, I don't want to
llvm/clang? I've ditched gcc because of its many unfixable problems. After
loosing quite some time, trying to cross-compile Go using gcc, I've
switched to clang IIRC and this works beautifully, especially
cross-building for Alpine/musl. However my AIX time with RS6000 was decades
ago, and I
I've noticed what looks at its surface that some code that is covered
doesn't show up in the cover profile data. Unfortunately, I don't have a
minimal example as I have no idea how to drill down. So please bear with my
explanations and hopefully it's a problem between VT100 and chair, I just
Forgive me if I missed that, but what if I have multiple context vars,
because I need to pass different (derived) contexts into different
functions/receivers? Take unit tests as real-world examples.
On Wednesday, February 21, 2024 at 1:37:05 AM UTC+1 Sam Vilain wrote:
> Alright, well thanks
carrier-grade NAT?
On Friday, February 2, 2024 at 7:05:42 PM UTC+1 sprynger wrote:
> In my case it might be an ISP problem, since this only happens to me when
> I work from home. At work, the exact same project builds all at once
> without any issues.
>
> A quinta-feira, 1 de fevereiro de 2024
https://github.com/thediveo/morbyd is a thin layer on top of the standard
Docker Go client to easily build and run throw-away test Docker images and
containers, and running commands inside them. It features a function option
API to keep the slightly excessive Docker API option parameters at
Are you still using Debian 11 and the outdated Debian docker.io package
with Docker 18? What happens when you use a recent Docker, either 24.x or
hot-off-the-press 25.0.1? And then build using a Go-Alpine base image? Do
you still use Debian's broken Docker seccomp profile...?
I'm on an IPv6
On Tuesday, January 9, 2024 at 2:28:08 AM UTC+1 Corin Lawson wrote:
On Tuesday 9 January 2024 at 1:12:00 am UTC+11 TheDiveO wrote:
One thing I notice is that your design assumes to specify the expected call
sequence upon creation, or do I get this wrong? My expectation would be to
specify this
a quick first lock looks promising to me: I like the blog post, as it
does IMHO a gentle introduction to your angle of attack. Having used
mocking (or one of its twins/cousins/... for those who insist on this not
being mocking, alas) on Python I've up to now found the Go mock packages to
be
Maybe your output is interfering with the way the go code base does some of
it's checks; based on the fail in cmd/vet maybe this could be involved:
https://github.com/golang/go/blob/b25f5558c69140deb652337afaab5c1186cd0ff1/src/cmd/vet/vet_test.go#L197?
On Tuesday, January 2, 2024 at 5:45:12 PM
s-o>.
To a large extend, this now excludes potential Go and/or
Ginkgo/Gomega-related effects, yet is consistent with my original
observation and question here.
On Sunday, December 17, 2023 at 6:02:17 AM UTC+1 Kurtis Rader wrote:
On Sat, Dec 16, 2023 at 7:54 AM 'TheDiveO' via golang-nuts &
, Dec 15, 2023 at 7:13 AM 'TheDiveO' via golang-nuts <
golan...@googlegroups.com> wrote:
I'm opening both named pipe ends as follows (in different processes):
os.OpenFile(fifoname, os.O_WRONLY, os.ModeNamedPipe)
os.OpenFile(fifoname, os.O_RDONLY, os.ModeNamedPipe)
Passing os.ModeNam
Please note that the unit test I linked to tests on the "writing end" of
the pipe. In fact, I wrote in the OP right in my first sentence:
> *Hi, I need to detect on the producer side (writing end) of a named pipe
when the consumer (reading end) has disconnect/closed. *
I'm afraid, but you are
hat illustrates a problem of this nature.
>
> On Fri, Dec 15, 2023 at 7:13 AM 'TheDiveO' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> Hi, I need to detect on the producer side (writing end) of a named pipe
>> when the consumer (reading end) has disconnect/
Hi, I need to detect on the producer side (writing end) of a named pipe
when the consumer (reading end) has disconnect/closed. This detection needs
to work "quickly" even if the producer doesn't produce anything; thus,
SIGPIPE wouldn't help.
On Linux, when using unix.Select() on the fd of the
IIRC the stdlib isn't delivered precompiled anymore since 1.20. You should
make sure to have layer caching in place in case you want to tune your
pipelines. You can do a "go build std" IIRC.
On Wednesday, December 13, 2023 at 4:40:21 PM UTC+1 Lib Martinito wrote:
>
> [image: Screenshot
You basically already showed how to do it on Linux: inside your Go prog,
you know the file descriptor number (f.Fd()). Then do an
os.Readlink(fmt.Sprintf("/proc/self/fd/%d", f.Fd()) and check the result
(if no error) with strings.HasSuffix(link, "(deleted)").
On Sunday, December 10, 2023 at
25 matches
Mail list logo
