You can add as a benefit to your module that it avoids the *supply chain
nightmare* that thereceipe/qt is (as you describe the latter: "It works by
making IPC calls to a separate C++ binary downloaded at runtime from a site
under the maintainer's control. This may be less performant than calling
were using the Linux with real-time kernel.
>
> On Sep 27, 2024, at 10:44 AM, 'TheDiveO' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> you need to keep a bunch of per-cpu ("per-core") kernel threads and you
> need to make sure not to st
just to be sure: you *do* actually use an RT kernel? I know you can set ff
on stock non-RT kernels, but the results can be quite different.
On Thursday, September 26, 2024 at 5:49:53 AM UTC+2 Zhao Weng wrote:
> Hi gophers,
> I'm doing a research on how to prioritise some goroutines over others.
:
>
> What you want to do is start the process with a cset to restrict the cores
> it can use - then use the setsched to move certain threads to cores that
> have been excluded.
>
> On Sep 27, 2024, at 10:26 AM, 'TheDiveO' via golang-nuts <
> golan...@googlegr
Are you running this on a multi-core? Your non-fifo tasks can be scheduled
to other cores, et cetera. BTW, fifo 99 is a recipe for desaster as it can
starve the kernel on a core, preventing necessary kernel house-keeping.
Don't ask me how I know...
What is the reason for setting GOMAXPROCS, I'm
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 w
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 und
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 I
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 maintaine
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
https://goplay.to
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
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 done
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 subs
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
-co
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 was
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
do
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 for
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 bay.
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 upl
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 d
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 U
gt;.
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' vi
n Fri, 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)
Pa
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 n
that 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) ha
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 p
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 2023-12-
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 5:4
30 matches
Mail list logo