Ah, xzutils issue is CVE-2024-3094, so hopefully unrelated.
On March 31, 2024 4:27:45 a.m. PDT, Russtopia! wrote:
>xz backdoor? Someone independently stumbled on it so do we all need to
>distrust our Go binaries until this is released? Embargo on this CVE may have
>been (accidentall
xz backdoor? Someone independently stumbled on it so do we all need to distrust
our Go binaries until this is released? Embargo on this CVE may have been
(accidentally) busted.
https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b
On March 29, 2024 2:40:07 p.m. PDT, annou...@go
, 2024 at 6:23 PM Robert Engels wrote:
> I would be also try reverting the Go version and ensure that it continues
> to work. Other system libraries may have been updated.
>
> > On Mar 2, 2024, at 12:05 PM, Ian Lance Taylor wrote:
> >
> > On Sat, Mar 2, 2024 at 9:59 AM R
nything.
On Sat, Mar 2, 2024 at 7:57 PM Russtopia wrote:
> It no longer does.. so it suggests to me there's something external that
> has changed, but I have no clue as to what that might be -- as the process
> being started by my go tool will run just fine from a shell. And, it *does*
with
exit status 0, no longer works -- it just gets 'killed').
On Sat, Mar 2, 2024 at 7:39 PM Robert Engels wrote:
> Please clarify - does it work using the older versions of Go?
>
> On Mar 2, 2024, at 12:53 PM, Russtopia wrote:
>
>
> I have tried rebuilding with
t 12:05 PM, Ian Lance Taylor wrote:
> >
> > On Sat, Mar 2, 2024 at 9:59 AM Russtopia wrote:
> >>
> >> Symptom: mysterious "signal: killed" occurrences with processes spawned
> from Go via exec.Cmd.Start()/Wait()
> >
> > The first step is to t
e Taylor wrote:
> On Sat, Mar 2, 2024 at 9:59 AM Russtopia wrote:
> >
> > Symptom: mysterious "signal: killed" occurrences with processes spawned
> from Go via exec.Cmd.Start()/Wait()
>
> The first step is to tell us the exact and complete error that you
> s
Hi all,
Symptom: mysterious "signal: killed" occurrences with processes spawned
from Go via exec.Cmd.Start()/Wait()
Actors:
'Server': Intel i5, running Funtoo 1.4 - 4GB RAM, 4GB swap
'Laptop': Intel Core i7 9thGen, running Devuan Chimaera - 15GB RAm, 15GB
swap
A quite small -- ~900 lines of cod
My bad ... I see too late that someone already filed an issue with the
molly-brown project about this.
https://tildegit.org/solderpunk/molly-brown/issues/16
On Wed, 16 Dec 2020 at 00:49, Russtopia wrote:
> The experimental 'Project Gemini' [https://gemini.circumlunar.space/
The experimental 'Project Gemini' [https://gemini.circumlunar.space/] has a
few servers written in Go, and one in particular [
https://tildegit.org/solderpunk/molly-brown] makes this claim:
It is very important to be aware that programs written in Go are unable to
> reliably change their UID once
Ah, bad form posting before I tried it in a plain CMD.EXE context.
The args are not transformed running from the vanilla command environment.
Guess it's a nasty interaction with MSYS.
-Russ
On Thu, 11 Jun 2020 at 20:03, Russtopia wrote:
> On windows, Go 1.14 running in my case unde
On windows, Go 1.14 running in my case under MSYS64
--
> package main
> import (
> "fmt"
> "os"
> )
> func main() {
> for idx, a := range os.Args {
> fmt.Printf("arg[%d]: %s\n", idx, a)
> }
> }
$ go run argtest.go foo foo:bar foo:/bar/baz
arg[0]:
I'm just a "rando" from the peanut gallery, but over the past 2 years I've
nearly *always* been able to find bindings with which to "hang things on" a
Go-based prototype, if indeed it wasn't already in the stdlib.
So golang has become my 'go-to' for prototyping, replacing Python entirely
for new w
o worry about whether or not it's supported in the
> browser. It seems to subvert what I'd perceive as the main goal of wasm:
> Decouple the browser engine from the code the developer wants to run in it.
>
>
>
> On Sun, Dec 22, 2019 at 9:16 AM Russtopia wrote:
>
&g
Crazy idea, but:
Now that wasm is 'official', why not push browser vendors to put the Go
runtime/stdlib, built for wasm, right into the browser so it doesn't need
to be downloaded with every single *.wasm project?
Of course, to be fair, not just Go -- why not also python-wasm-runtime,
c-wasm-runt
Hi all,
I'm trying to use the technique here
https://medium.com/@felixge/killing-a-child-process-and-all-of-its-children-in-go-54079af94773
.. to ensure all children/grandchildren of my exec of /bin/bash die along
with it, but I am getting the above 'operation not permitted' error when
trying to
Score one in support for this, from the "peanut gallery" of "experienced
programmers in other languages, but only around 2 years of Go". I thought
at first that if err != nil { ... } seemed clumsy, but I myself don't like
exceptions and implicit flow control constructs much and the more I used
Go,
Perhaps a dumb question and if so I apologize in advance. Reading the
page at https://proxy.golang.org/ I'm unclear as to how the index is
being populated. Is there an API to submit modules to the index, or is
it curated by real humans, and what is the process if so, etc.
Does one have to host one
Hi all,
I've tried running some of my Go code using CPU Profiling enabled as
described at
https://blog.golang.org/profiling-go-programs
and
https://golang.org/pkg/runtime/pprof/#StartCPUProfile
.. I'm on Funtoo Linux x86_64, and I ensured CONFIG_HIGH_RES_TIMERS=y;
however, it seems no matter w
I have used gopherjs for some small projects; it's pretty nice and lets you
'think in Go' yet still access the DOM pretty easily.
I am no JS expert, so using it let me sidestep some of the ugliness there.
It definitely made doing async stuff nicer, using goroutines instead of
lots of callback-style
@Tamás Gulácsi
I just wanted to thank you for your advice -- this works wonderfully.
I am still surprised by how Go's type system and thoughtful stdlib design
allows clever ways to override and extend standard behaviours without a lot
of code and complexity!
On Sat, 26 Jan 2019 at 00:46, Tamá
If anyone's curious I've already devised a patch and submitted a PR to add
hooks for styling directory pages served from http.FileServer(): (no
warranty, of course)
https://github.com/Russtopia/go/commit/ff2a26eee79f8c9338c94c30d2fa1d2b9934daf6
-R.
On Fri, 25 Jan 2019 at 18:46, Russto
Hi all,
I'm doing an app which serves out its own endpoints via http.HandleFunc()
and so on, and of course it's easy to customize the content and layout of
these endpoints; but I also server out some filesystem trees using
http.FileServer().
This unfortunately seems to restrict one to the very pl
umber in some formatting.
>
> i think you're up against a "go attitude" decision here but it could help
> support the tooling spirit...would be nice to see the list if these at exit
> to quickly spot leaking
>
> On Sun, Nov 25, 2018 at 8:05 PM Russtopia wrote:
>
&g
t holds
> the anonymous function, defaulting to func#n when it's a func literal.
> This should be able to be gleaned from the analysis.
>
> On Sun, 2018-11-25 at 16:04 -0800, Russtopia wrote:
> > That still doesn't address what I'm getting at -- it doesn't give a
a FAQ Abbott this, if I understand what you want correctly:
> https://golang.org/doc/faq#no_goroutine_id
>
> On Sun, Nov 25, 2018, 4:04 PM Russtopia
>> That still doesn't address what I'm getting at -- it doesn't give a
>> semantically meaningful name to
aningful nodes in the graphviz output
hinting at what each goroutine does, by its enclosing function
(spawnWorkerA, spawnChannelWatcher) at the expense of some extra nodes in
the diagram.
On Sun, 25 Nov 2018 at 16:04, Russtopia wrote:
> That still doesn't address what I'm get
could label the anonymous functions by their
> filepath:line number or something else.
>
> On Sun, 2018-11-25 at 15:12 -0800, Russtopia wrote:
> > I recently tried out a go tool for outputting code structure
> > visualization
> > using graphviz -- https://github.com/TrueF
I recently tried out a go tool for outputting code structure visualization
using graphviz -- https://github.com/TrueFurby/go-callvis
I found that goroutines are just labelled $1 or similar
by go-callvis. I could of course be wrong, but my thinking is that this is
not really a shortcoming of graphv
Perhaps this is actually supported in Go v1 and I'm just missing something
simple, but it appears one can do
func A() {
go func() {
...
}()
}
but not
func A() {
go func B() {
...
}()
}
or even
func A() {
func B() {
..
}
go B()
}
Does the syntax just not allow nami
This is really interesting! I have only viewed the slideshow quickly, and
have no idea how applicable it would be, but there are projects for getting
Go to run on bare-metal:
https://www.youtube.com/watch?v=8T3VxGrrJwc
if that could be combined or leveraged to run Biscuit, a POSIX kernel 100%
fre
31 matches
Mail list logo
