Re: [go-nuts] [security] Go 1.22.2 and Go 1.21.9 pre-announcement

[Russtopia!]

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 (accidentally) busted.
>
>https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b
>
>On March 29, 2024 2:40:07 p.m. PDT, annou...@golang.org wrote:
>>Hello gophers,
>>
>>We plan to issue Go 1.22.2 and Go 1.21.9 during US business hours on 
>>Wednesday, April 3.
>>
>>These minor releases include PRIVATE security fixes to the standard library, 
>>covering the following CVE:
>>
>>- CVE-2023-45288
>>
>>Following our security policy, this is the pre-announcement of those releases.
>>
>>Thanks,
>>Than and Dmitri for the Go team
>>
>>-- 
>>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 discussion on the web visit 
>>https://groups.google.com/d/msgid/golang-nuts/aALo8CEjSde7JcBYKiKpaQ%40geopod-ismtpd-4.

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/10CAD9C1-51CB-488B-8331-C11DAAD4D942%40gmail.com.

Re: [go-nuts] [security] Go 1.22.2 and Go 1.21.9 pre-announcement

[Russtopia!]

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...@golang.org wrote:
>Hello gophers,
>
>We plan to issue Go 1.22.2 and Go 1.21.9 during US business hours on 
>Wednesday, April 3.
>
>These minor releases include PRIVATE security fixes to the standard library, 
>covering the following CVE:
>
>-  CVE-2023-45288
>
>Following our security policy, this is the pre-announcement of those releases.
>
>Thanks,
>Than and Dmitri for the Go team
>
>-- 
>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 discussion on the web visit 
>https://groups.google.com/d/msgid/golang-nuts/aALo8CEjSde7JcBYKiKpaQ%40geopod-ismtpd-4.

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/C0B7DDD0-0436-4684-8688-7D9EABE53265%40gmail.com.

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

[Russtopia]

SOLVED!

Thank you all for the helpful suggestions. Although it has turned out to be
something totally different, and a teachable lesson in web app design...

This go tool of mine has a very simple web interface with controls for a
set of jobs on the main page.
The jobs on this list can be run, viewed, and most importantly, cancelled
via an endpoint of the form "/cancel/?id=nnn" ...
I have had the site up in a "demo" mode on the public internet at various
times, including recently -- it turns out that very recently some crawl
bots must have found it, and they are following those /cancel/ links on the
dashboard almost as soon as they appear -- they must be scanning at <5sec
intervals to find the new unique jobIDs encoded in each 'cancel' link. Oops
:)

The app's usually behind an auth page, but this time it wasn't. I'm not a
web dev so rookie mistake I suppose!
I guess I really should have a 'robots.txt' file served out by my go app to
prevent this, and perhaps consider other client session ids to prevent
outside crawlers from accidentally activating my app's link endpoints.

Thank you again, all.

On Sat, Mar 2, 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 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
> > see.  "signal: killed" can have different causes, and the rest of the
> > information should help determine what is causing this one.
> >
> > Ian
> >
> > --
> > 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 discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXR6hBSnGLjehwng%2BXp4QQ8ZznramEAZTmD%3D6tVwFirTg%40mail.gmail.com
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu8DRA-iPvuC_r4ToGAoADRG_ejYBCTVQ060O0tSK1rESA%40mail.gmail.com.

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

[Russtopia]

.. I should add that I have often completely restarted the go program
during testing here, so I don't think it could be a case of some long-term
'leak' in the go tool's own code since it's been relaunched and doesn't
have any big 'state' to restore or anything.

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*
> run fine on my laptop (which granted is beefier, but again this server was
> running the tool just fine for years and I haven't done any big upgrades,
> but it *is* possible some minor underlying package update has severely
> changed the environment somehow). Unfortunately I don't have a system-wide
> 'snapshot' I can revert to.
>
> Perhaps this will end up being a question of Linux diagnostics more than
> Go but I haven't yet seen any way to tell *why* the process is being
> killed, whether it be due to some bug tickled by Go's exec or something
> else. The oom_reaper doesn't say a thing to system logs; I don't see my
> free RAM or swap suddenly drop.. I've even checked my server for rootkits
> out of paranoia :). Everything else on the system is just fine, I just
> cannot seem to run these scripts any more when launched from my go program
> (again, even a 'do-nothing' script that just sleeps a few times, then
> completes 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 go1.18.6, go1.15.15 with no difference.
>>
>> On Sat, Mar 2, 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 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
>>> > see.  "signal: killed" can have different causes, and the rest of the
>>> > information should help determine what is causing this one.
>>> >
>>> > Ian
>>> >
>>> > --
>>> > 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 discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXR6hBSnGLjehwng%2BXp4QQ8ZznramEAZTmD%3D6tVwFirTg%40mail.gmail.com
>>> .
>>>
>>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu_ZdjevdFUiMbCtmHk44rEi-zHeye4L-mTe11TT8G2eNg%40mail.gmail.com.

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

[Russtopia]

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*
run fine on my laptop (which granted is beefier, but again this server was
running the tool just fine for years and I haven't done any big upgrades,
but it *is* possible some minor underlying package update has severely
changed the environment somehow). Unfortunately I don't have a system-wide
'snapshot' I can revert to.

Perhaps this will end up being a question of Linux diagnostics more than Go
but I haven't yet seen any way to tell *why* the process is being killed,
whether it be due to some bug tickled by Go's exec or something else. The
oom_reaper doesn't say a thing to system logs; I don't see my free RAM or
swap suddenly drop.. I've even checked my server for rootkits out of
paranoia :). Everything else on the system is just fine, I just cannot seem
to run these scripts any more when launched from my go program (again, even
a 'do-nothing' script that just sleeps a few times, then completes 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 go1.18.6, go1.15.15 with no difference.
>
> On Sat, Mar 2, 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 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
>> > see.  "signal: killed" can have different causes, and the rest of the
>> > information should help determine what is causing this one.
>> >
>> > Ian
>> >
>> > --
>> > 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 discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXR6hBSnGLjehwng%2BXp4QQ8ZznramEAZTmD%3D6tVwFirTg%40mail.gmail.com
>> .
>>
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu-3VDej9EGtQ%3D6wcrU0fi5T67R5et%2BbVek10XHyXNngYg%40mail.gmail.com.

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

[Russtopia]

I have tried rebuilding with go1.18.6, go1.15.15 with no difference.

On Sat, Mar 2, 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 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
> > see.  "signal: killed" can have different causes, and the rest of the
> > information should help determine what is causing this one.
> >
> > Ian
> >
> > --
> > 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 discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXR6hBSnGLjehwng%2BXp4QQ8ZznramEAZTmD%3D6tVwFirTg%40mail.gmail.com
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu_btPr9-PntaH6Vq7Uf4%3D%3DNnd%2B20MJUktXhBq14ZzEPdw%40mail.gmail.com.

Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

[Russtopia]

Hi, I tried outputting the value of werr.(*exec.ExitError).Stderr, but it's
empty.

Outputting all of werr.(*exec.ExitError) via

fmt.Printf("[job *ExitError:%+v]\n", werr.(*exec.ExitError))

..gives merely

[job *ExitError:signal: killed]



On Sat, Mar 2, 2024 at 6:04 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 tell us the exact and complete error that you
> see.  "signal: killed" can have different causes, and the rest of the
> information should help determine what is causing this one.
>
> Ian
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu_QqCHMuZnCkc%3DoH7e5uJLS4mfcK5zSa15ehzFUeUn2BQ%40mail.gmail.com.

[go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code

[Russtopia]

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 code in two .go files, program I developed
which has been running for years just fine on 'Server', which spawns and
monitors other programs using exec.Cmd.Start() and then uses
exec.Cmd.Wait() to monitor them, started acting very strangely a few days
ago, after either: upgrading from go 1.18 to go 1.22 (amd64), and/or non-
Go related minor updates (regretfully I don't recall exactly what, but it
was not a distro or kernel upgrade, nor a major version of glibc or
anything like that).

What used to be smoothly launched tasks from my Go program became
erratically (then almost always) aborted jobs, with the status of "signal:
killed". I can watch the system with 'top or 'htop' and don't see any
obvious spikes in mem or CPU usage, and never have with this setup
beforehand either.

I spent a few evenings verifying 'Server' wasn't out of memory
(oom_reaper), as many web searches suggest is the biggest cause of the
above, and other system-related things with no luck (no oom logs in
/var/log/kern.log, dmesg, etc.).

I even tried launching my go program with some of the debug options
mentioned here, but didn't see anything unusual:

https://github.com/golang/go/issues/31517

Everything else on 'Server' ran fine, so I began to suspect the
unthinkable: could the new Go toolchain 1.22.0 I installed have some subtle
issue with the server's runtime environment, or could there be a compiler
bug?

Out of habit, after any go update I usually rebuild this project using the
new toolchain, which I believe I had done just before this issue began; so
first I reverted to go1.18 on 'Server' (there as a fallback), and rebuilt
my tool; no help. I tried clearing out all of ~/go/pkg/mod/* and refetched
all dependencies, rebuilt again. Still no help.

Then I tried building the project on another machine, 'Laptop', which had
go1.21.0; on this machine it ran fine. So I copied *that* build of the tool
back to 'Server', and it failed with "sign: killed" as well.

I tried the reverse ('Server' build of project, using go1.22.0 copied to
'Laptop' using go1.18.x) but that failed, as there was a GLIBC
incompatibility preventing it running. (I think Funtoo had a slightly newer
GLIBC version than Devuan).

Anyhow, in case it *was* a go toolchain or C library issue beneath Go
itself, I downloaded the latest go 1.22.0 source to 'Server' and rebuilt it
there from scratch (all.bash); using that to rebuild my tool I was happy to
see it now worked normally again... for about 5 rounds of spawning
programs, then the issue returned!

The 'Server' isn't very powerful, but it's definitely not out of memory and
has run my tool reliably for a long time, until the last week:

$ free
   totalusedfree  shared  buff/cache
available
Mem: 3928680 1334988  592232   29368 2001460
2277376
Swap:4194300  136192 4058108

This issue even occurs spawning a simple 'do-nothing' shell script, which
just loops sleeping for 5 seconds a few times before exiting. These
processes/scripts run perfectly from the shell command line, without using
my Go program to launch them.

What the heck is going on? How do I diagnose this?

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu8Knootg-4%3DNS_EPzLKssg18Lv4f6QZ%2B16-gMBB-kaHSw%40mail.gmail.com.

[go-nuts] Re: Is this really true? (Go 'unable to reliably change their UID once started for goroutines' ?)

[Russtopia]

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/] 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 started, due to how goroutines are
>> implemented on unix systems. As an unavoidable consequence of this, CGI
>> processes started by Molly Brown are run as the same user as the server
>> process.
>
>
> Surely this is not true? This claim seems to suggest a big security issue
> that I would hope can be refuted by Go experts -- perhaps the maintainers
> of the molly-brown project could be guided to a solution so this
> scary claim could be removed.
>
> I wanted to try out the above server but am hesitant to do so given the
> above ...
>
> -R.
>
>
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu8jcGfx0tuW7YL3itVh-k1YYxYTSRAaB_bCLdNBce_RpA%40mail.gmail.com.

[go-nuts] Is this really true? (Go 'unable to reliably change their UID once started for goroutines' ?)

[Russtopia]

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 started, due to how goroutines are
> implemented on unix systems. As an unavoidable consequence of this, CGI
> processes started by Molly Brown are run as the same user as the server
> process.


Surely this is not true? This claim seems to suggest a big security issue
that I would hope can be refuted by Go experts -- perhaps the maintainers
of the molly-brown project could be guided to a solution so this
scary claim could be removed.

I wanted to try out the above server but am hesitant to do so given the
above ...

-R.

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu9Su_-N%2BPD-ULG_hv68sPs2JAr7%2BpuTBHpMN7s%3DRaA%2Bcg%40mail.gmail.com.

[go-nuts] Re: Why does Go transform os.Args[] with colons in this way (win32/x64)

[Russtopia]

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 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]: C:\msys64\tmp\go-build182983234\b001\exe\argtest.exe
> arg[1]: foo
> arg[2]: foo:bar
> arg[3]: foo;C:\msys64\bar\baz
>
>
> Note that last arg: seems Go converts 'foo:' to 'foo;C:' and then
> interprets the rest as an absolute unix path to be converted to a DOS-style
> path!
>
> Is there a good rationale why this is done?
> For context, I am writing a utility that I want to specify paths in the
> style of openssh/scp, eg. hostname:path without Go munging them into
> Windows-style paths.
>
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu8eJhi8PhgXWqh%2Bs%2BNJez1zthaGOMUNAcxTyyqe0nnxNw%40mail.gmail.com.

[go-nuts] Why does Go transform os.Args[] with colons in this way (win32/x64)

[Russtopia]

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]: C:\msys64\tmp\go-build182983234\b001\exe\argtest.exe
arg[1]: foo
arg[2]: foo:bar
arg[3]: foo;C:\msys64\bar\baz


Note that last arg: seems Go converts 'foo:' to 'foo;C:' and then
interprets the rest as an absolute unix path to be converted to a DOS-style
path!

Is there a good rationale why this is done?
For context, I am writing a utility that I want to specify paths in the
style of openssh/scp, eg. hostname:path without Go munging them into
Windows-style paths.

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu_wdDAYjwSSanTjo-0aGNR6gqcdhW6qb1-2YydBCwMf_g%40mail.gmail.com.

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

[Russtopia]

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 work. One of the main drivers for me taking the dive into golang
from C and Python was the superb tooling and lightning-fast build/test/run
cycle it enabled, which felt almost as low-friction as Python.

On Mon, 27 Jan 2020 at 11:55, Robert Engels  wrote:

> easy prototyping != scaling
>
> Pick one.
>
>
>
> On Jan 27, 2020, at 1:42 PM, Liam Breck  wrote:
>
> 
> Go mindshare suffers if it's seen as worse for prototyping, and necessary
> only for scale. Especially as there are more efficient (albeit more
> complex) ways to achieve scale.
>
> On Mon, Jan 27, 2020, 10:55 AM Eric S. Raymond  wrote:
>
>> Michael Jones :
>> > Python, to its credit, has the nice inclusive property of extensible
>> > interpreters of being friendly to "hang things" onto just like
>> ornaments on
>> > trees. By linking with C/C++-libraries and adding glue/shim code,
>> anything
>> > can be used from Python. This facility and interpretive execution (as
>> Eric
>> > Johnson observed above) makes it a natural for discovery and trying of
>> > things.
>> >
>> > These virtues may seem less so in eventual deployments, at scale, and in
>> > other cases.
>>
>> True, and connects directly to my recent experience report.
>>
>> Python was the best language to prototype reposurgeon in,
>> but scale pressure forced the move to Go.
>> --
>> http://www.catb.org/~esr/;>Eric S. Raymond
>>
>>
>> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAKvHMgRSCF5MQW4CTew5kD4KKNkdt4X7c0X1gqDq6Bxyz98ssQ%40mail.gmail.com
> 
> .
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/BE504CA9-0E8F-4B09-8522-CDC7139F264B%40ix.netcom.com
> 
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu_WyzHDrLvvtectUbRZndTDtaxL5AKmhL7BMBVWaUd96w%40mail.gmail.com.

[go-nuts] Re: Now that wasm is 'standard'... bundle common lang runtimes with browsers

[Russtopia]

Points well taken. Hadn't considered that simply caching should negate any
load time issues.

Also agreed, reinventing applets is probably a bad idea... 
No more posting hare-brained ideas whilst half-asleep :)

Cheers,
-R.

On Sunday, 22 December 2019, Robert Engels  wrote:

> Pretty much the JVM in the browser all over again... if I can live long
> enough maybe I can see people touting the ergonomics and simplicity of the
> 3270.
>
> On Dec 22, 2019, at 5:33 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> ISTM that this requires being able to distribute the runtime of the
> language separately from the "user code" and link them together again
> successfully. Once you have that - it seems a problem far better solved by
> decent caching. That is, as a Go-user, I'd put a "load Go runtime from
> https://golang.org/wasm/" or something in my page. That
> resource is then infinitely cacheable, thus must only be downloaded
> approximately once (just as if it's bundled). What you get is, that as a
> developer, you don't need to wait until your favorite version of the
> runtime of your favorite language is available in all common browsers.
>
> I'd see "the runtime is bundled with a browser" as replicating exactly the
> main problem with javascript - that you can't use all its features, because
> you constantly have to 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:
>
>> 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-runtime, rust-std-runtime, ...
>>
>> This would require some sort of 'runtime plugin' standard with
>> versioning, feature-query and supply-chain security/update mechanisms, of
>> course, but wouldn't it be nice?
>>
>> I've been playing with gopherjs and go-wasm, and the big downside to both
>> is that the baseline *.js file is 1.5-2MB or more, due to bundling a
>> complete language runtime that must download with every app.
>>
>> With official 'blessed' wasm runtimes for major languages we could
>> finally break the deadlock on JS in the browser.
>>
>> --
>> 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 discussion on the web visit https://groups.google.com/d/
>> msgid/golang-nuts/CAN4yCu_nHObFToYaM-7CwuiK42EWGinVZNGZt0Ow4x73DXu5
>> 2Q%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAN4yCu_nHObFToYaM-7CwuiK42EWGinVZNGZt0Ow4x73DXu52Q%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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 discussion on the web visit https://groups.google.com/d/
> msgid/golang-nuts/CAEkBMfGF%2BYbMWk0hAzU2GTFLXLbsJ4pvurejV
> VNrZF43Yh0kZA%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGF%2BYbMWk0hAzU2GTFLXLbsJ4pvurejVVNrZF43Yh0kZA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu9j9m1T%3Ds8a90REdGnAK5Ztxd-zEP6QFWS9om-BXY0hPA%40mail.gmail.com.

[go-nuts] Now that wasm is 'standard'... bundle common lang runtimes with browsers

[Russtopia]

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-runtime, rust-std-runtime, ...

This would require some sort of 'runtime plugin' standard with versioning,
feature-query and supply-chain security/update mechanisms, of course, but
wouldn't it be nice?

I've been playing with gopherjs and go-wasm, and the big downside to both
is that the baseline *.js file is 1.5-2MB or more, due to bundling a
complete language runtime that must download with every app.

With official 'blessed' wasm runtimes for major languages we could finally
break the deadlock on JS in the browser.

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu_nHObFToYaM-7CwuiK42EWGinVZNGZt0Ow4x73DXu52Q%40mail.gmail.com.

[go-nuts] fork/exec /bin/bash: operation not permitted

[Russtopia]

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 Start(). It works fine without Setpgid set, but when my /bin/bash
dies, any background children spawned from it are left running, adopted by
init (pid 1).

Any idea why setting syscall.SysProcAttr{Setpgid: true} might not work
with  certain other attributes set? My program is a daemon running as root,
and sets Uid/Gid to another non-root user; it also uses github.com/kr/pty,
the Start() method of which also sets some other attributes, .Setctty and
.Setsid. I tried going through the golang stdlib startProcess() code and
related bits, but don't fully understand how all of these optional flags
interact.

Thanks,
-Russ

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu-wxW6tfEcryOmkJUU6J3oVX6R3pHeOhpJFKsuReU%2BPhg%40mail.gmail.com.

Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

[Russtopia]

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, the more natural it felt. If anything, a way to pretty-print stack
traces would be the main thing I'd like to more quickly parse failure
paths, though I have seen at least one project already that does this so it
needn't be a core part of the language.

A gofmt one-line with return style as described here seems like a very nice
balance to me.


On Tue, 2 Jul 2019 at 19:41, Dave Cohen  wrote:

>
>
> On Friday, June 28, 2019 at 5:44:01 PM UTC-7, Tyler Compton wrote:
>>
>> If anyone hasn't seen it, an issue with the "proposal" tag was created
>> earlier on the Go issue tracker titled "Proposal: leave "if err != nil"
>> alone?" (here ). This issue seems to
>> have resonated with a lot of people, which may be an important data point
>> when considering the try proposal , but
>> I was surprised to see how poorly the discussion has gone. There are quite
>> a few "me too" comments, a few image-only posts, some less than stellar
>> personal conduct, and overall not a lot of nuanced discussion. I feel that
>> perhaps these kinds of anti-proposals should be discouraged because they're
>> inherently reactionary, which seems to get the discussion off on the wrong
>> foot.
>>
>> That said, this anti-proposal attracted a whole new group of Go users
>> that I don't remember from the original try proposal discussion, which was
>> mostly dominated by ten or twenty participants. The discussion was better,
>> but the number of active users was much smaller. I wonder if there's a way
>> to better engage a larger portion of the Go user base while still
>> encouraging healthy, technical discussion.
>>
>
> I've noticed that `go fmt` generally format funcs into multiple lines, but
> does allow one-liners. That is, it will leave a function like this as just
> one line:
>
> func statusUpdate() string { return "" }
>
> (For more examples, grep "{ return" in the standard library.)
>
> While I know that "one line if statements" have been discussed and
> over-discussed, I'll go out on a limb and suggest maybe `go fmt` should
> allow a "one line if" in one circumstance...are you ready for it? when
> the then clause contains only a `return ...`.
>
> This means the following would be allowed by `go fmt`...
>
> if err != nil { return err }
>
> or
>
> if err != nil { return fmt.Errorf("I like to wrap my errors: %s", err)
> }
>
> This makes error handling more concise, by some lines, in those cases
> handled by the `try` proposal.  And also more concise while allowing
> wrapping or testing for error values other than nil.
>
> It's a modest proposal in that it only saves lines of code.  It requires
> no language changes, just `go fmt` changes. This would be analogous to what
> `go fmt` already allows in one line funcs, and in my opinion would not
> negatively affect readability.  If enough folks here reach out to me
> supporting this idea, I'd submit a proper proposal.
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/42b8fc5d-2f0a-4951-8ca5-0476e23fd4a7%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu-pgQfFkoHPvrSF9DmrK%2BXs9ju6t7%2BS81z-F0U_TMqBGQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] How does proxy.golang.org discover modules to index?

[Russtopia]

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's modules at a 'blessed' site to make it
into this new index? I see big players like github.com, golang.org,
but other non-corporate domains as well, in
https://index.golang.org/index

-R.

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu82S2nFEgnZKEEbu2naZeX5Z8XvZ%2B2fYjNVmbTAC1v3kg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] pprof - Trouble getting any data from pprof.StartCPUProfile()

[Russtopia]

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 what I always end up with a profile output
file of zero bytes.

I tried adding the HTTP endpoint for /debug/ to see profiling and
heap, allocs, and a few others do yield data.. it's just a few such as
pprof are always 0.

1. Is there another kernel config I might be missing for supporting this?
2. There's mention elsewhere of the SIGPROF signal, does my program
*need* to listen for this signal and receive one or more to actually
yield pprof data?

Thanks,
-Russ

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN4yCu-gDmJOtWfqVrBokipccJGtvo3UduCcnGzmRx24oiJkpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is WASM support planned in go 1.12 ?

[Russtopia]

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 constructs.

On Wed, 6 Feb 2019 at 12:31, Tharaneedharan Vilwanathan 
wrote:

> Somehow I was dreaming I can use Go for frontend too, instead of JS. Is my
> thinking right?
>
> Regards
> dharani
>
>
> On Wed, Feb 6, 2019 at 12:26 PM Robert Engels 
> wrote:
>
>> Just mo wasm is horrible on any platform. Unless you maybe have a
>> large game engine that you are attempting to integrate.
>>
>> You have to ask yourself, what are you trying to do? If it is just to
>> avoid the garbage that is JS, then use an environment that transpiles to
>> JS. You’ll have better integration with the DOM, and not have to learn yet
>> another client side technology.
>>
>> Again, just mo.
>>
>> On Feb 6, 2019, at 2:06 PM, Tharaneedharan Vilwanathan <
>> vdhar...@gmail.com> wrote:
>>
>>
>> I have one more question. Has anyone used WASM in Go for something more
>> than small examples I managed to see and got them working?
>>
>> It was challenging to get it working and then I wasn't sure how it is
>> used and how to use it for any bigger projects.
>>
>> Please share your thoughts.
>>
>> Regards
>> dharani
>>
>>
>> On Wed, Feb 6, 2019 at 11:57 AM gocss 
>> wrote:
>>
>>> while webassembly was considered experimental in go 1.11 is it
>>> planned in go 1.12 release later this month? If so will it's inclusion
>>> be considered non-experimental ?
>>>
>>> --
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Restyle output of net/http/fs.go dirList() ?

[Russtopia]

@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ás Gulácsi  wrote:

> Something along the lines of https://play.golang.org/p/YgVIP_6uIWG can
> work.
>
> 2019. január 26., szombat 8:36:59 UTC+1 időpontban Tamás Gulácsi a
> következőt írta:
>>
>> dirList is just 20 lines of code, you can easily reimplement it with your
>> decorators.
>>
>> To ake this as an extension of ServeFile, you have to embed ServeFile
>> into your struct, and implement a ServeHTTP method which prints dirs as you
>> wish if the request is a GET of a directory, but call the embedded
>> ServeFile.ServeHTTP otherwise.
>>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Restyle output of net/http/fs.go dirList() ?

[Russtopia]

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, Russtopia  wrote:

> 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 plain-vanilla output
> for directories hardcoded within the un-exposed dirList() function within
> fs.go.
>
> https://golang.org/src/net/http/fs.go?s=20537:20577#L598
>
> Is there a clever go way of extending net/http just to change dirList(),
> without duplicating most of its code?
>
> If only dirList() were enhanced to check for an optionally-set user
> override func(), calling that instead when specified, anyone could easily
> style their fileservers' directory views. I'm not proposing bringing
> templates into net/http -- it would be the user's responsibility to use
> such things in their custom handlers, if desired.
>
> Any ideas of another way to do this short of cloning net/http and internal
> dependencies?
>
> -Russ
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Restyle output of net/http/fs.go dirList() ?

[Russtopia]

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 plain-vanilla output
for directories hardcoded within the un-exposed dirList() function within
fs.go.

https://golang.org/src/net/http/fs.go?s=20537:20577#L598

Is there a clever go way of extending net/http just to change dirList(),
without duplicating most of its code?

If only dirList() were enhanced to check for an optionally-set user
override func(), calling that instead when specified, anyone could easily
style their fileservers' directory views. I'm not proposing bringing
templates into net/http -- it would be the user's responsibility to use
such things in their custom handlers, if desired.

Any ideas of another way to do this short of cloning net/http and internal
dependencies?

-Russ

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

[Russtopia]

Sure. I just found it a very interesting 'corner' of the language I have
run up against.
However, I do have what I think is an ingenious solution which
unfortunately cannot fit in the margin of this email :). It's actually
working rather well for my purposes, and I've proposed it already to the
author of go-callvis. We'll see where it goes.

I think given the Go philosophy of keeping the language itself simple, a
convention for annotating goroutines (and defer blocks which also show up
in graphvis in the same manner) via comments might be best. A
post-processing tool to catch these comments and fix up the graphviz .dot
output is already showing promise in achieving what I am after.

-Russ

On Sun, 25 Nov 2018 at 20:13, Michael Jones  wrote:

> just saying the we could make it so. the full name (for a func local var)
> would be funcName_varName_instanceNumber 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:
>
>> Perhaps I misunderstand what you suggest, but I tried
>>
>> func A() {
>>...
>>descriptivelyNamedGoroutine := func() {
>>...
>>}
>>...
>>descriptivelyNamedGoroutine()
>>...
>>
>> Alas, the 'dot' tool used by go-callvis doesn't seem to obtain any
>> additional info from this. The resulting diagram still just labels the
>> goroutine A$1.
>> Perhaps a limitation of go-callvis itself; I've mailed the author with
>> this issue to see what he/she thinks about it.
>>
>>
>> On Sun, 25 Nov 2018 at 16:36, Dan Kortschak <
>> dan.kortsc...@adelaide.edu.au> wrote:
>>
>>> A way around that might be to use the name of the variable that 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
>>> > semantically meaningful name to the goroutines, in stack traces,
>>> > source
>>> > code, or in code visualization tools such as graphviz diagrams.
>>> >
>>> > What does that goroutine actually *do*? Is it a worker for some
>>> > specific
>>> > purpose, does it read from stdin and forward to a pty/socket, does it
>>> > wait
>>> > for data on some channel, does it sleep until a particular event
>>> > occurs and
>>> > then reboot the box ... ? 'EnclosingFunc$1', 'EnclosingFunc$2' aren't
>>> > very
>>> > useful names for documentation and the current Go syntax allows no
>>> > specification of this by naming the goroutine itself, short of moving
>>> > it
>>> > completely out of the scope of the enclosing named function, and
>>> > losing the
>>> > benefits of a closure.
>>> >
>>> > I guess what I'm getting at is that goroutines can't be named for
>>> > what they
>>> > *mean* or *do*. Comments can of course explain this within the source
>>> > code,
>>> > but I think there would be a concrete benefit to defining a
>>> > convention for
>>> > comment-tagging goroutines, in provide this foothold for external
>>> > documentation tools; or, perhaps even better, a way to actually name
>>> > goroutines like how GCC allows named, nested functions. This could
>>> > even
>>> > improve the readability of stack traces could it not?
>>> >
>>> > I've already devised a 'comment above each goroutine' hack, plus a
>>> > post-processing tool (basically a sed script) to massage the output
>>> > of the
>>> > graphviz 'dot' data, where I place info above each goroutine so it
>>> > can be
>>> > renamed in the output diagram. That addresses the naming issue within
>>> > graphviz diagrams for me, for now.
>>> >
>>> >
>>> > On Sun, 25 Nov 2018 at 15:28, Dan Kortschak >> > du.au>
>>> > wrote:
>>> >
>>> > >
>>> > > That package doesn't introspect on running code, so a goroutine
>>> > > name is
>>> > > not necessary. go-callvis could label the anonymous functions by
>>> > > their
>>> > > filepath:line number or something else.
>>> > >
>>> > >

Re: [go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

[Russtopia]

Perhaps I misunderstand what you suggest, but I tried

func A() {
   ...
   descriptivelyNamedGoroutine := func() {
   ...
   }
   ...
   descriptivelyNamedGoroutine()
   ...

Alas, the 'dot' tool used by go-callvis doesn't seem to obtain any
additional info from this. The resulting diagram still just labels the
goroutine A$1.
Perhaps a limitation of go-callvis itself; I've mailed the author with this
issue to see what he/she thinks about it.


On Sun, 25 Nov 2018 at 16:36, Dan Kortschak 
wrote:

> A way around that might be to use the name of the variable that 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
> > semantically meaningful name to the goroutines, in stack traces,
> > source
> > code, or in code visualization tools such as graphviz diagrams.
> >
> > What does that goroutine actually *do*? Is it a worker for some
> > specific
> > purpose, does it read from stdin and forward to a pty/socket, does it
> > wait
> > for data on some channel, does it sleep until a particular event
> > occurs and
> > then reboot the box ... ? 'EnclosingFunc$1', 'EnclosingFunc$2' aren't
> > very
> > useful names for documentation and the current Go syntax allows no
> > specification of this by naming the goroutine itself, short of moving
> > it
> > completely out of the scope of the enclosing named function, and
> > losing the
> > benefits of a closure.
> >
> > I guess what I'm getting at is that goroutines can't be named for
> > what they
> > *mean* or *do*. Comments can of course explain this within the source
> > code,
> > but I think there would be a concrete benefit to defining a
> > convention for
> > comment-tagging goroutines, in provide this foothold for external
> > documentation tools; or, perhaps even better, a way to actually name
> > goroutines like how GCC allows named, nested functions. This could
> > even
> > improve the readability of stack traces could it not?
> >
> > I've already devised a 'comment above each goroutine' hack, plus a
> > post-processing tool (basically a sed script) to massage the output
> > of the
> > graphviz 'dot' data, where I place info above each goroutine so it
> > can be
> > renamed in the output diagram. That addresses the naming issue within
> > graphviz diagrams for me, for now.
> >
> >
> > On Sun, 25 Nov 2018 at 15:28, Dan Kortschak  > du.au>
> > wrote:
> >
> > >
> > > That package doesn't introspect on running code, so a goroutine
> > > name is
> > > not necessary. go-callvis 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/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 graphviz, but rather a lack of
> > > > support
> > > > for
> > > > naming goroutines within the language itself as goroutines are
> > > > also
> > > > 'unnamed' in this sense within stack traces. It would aid in
> > > > understanding
> > > > the purpose of goroutines within a structure diagram if
> > > > goroutines
> > > > could be
> > > > named somehow.
> > > >
> > > > I was hoping there was a way within Go to give goroutines
> > > > meaningful
> > > > names
> > > > in such a way that graphviz-like tools could pick up on it and
> > > > make
> > > > meaningful annotations.
> > > >
> > > > The runtime would, I suppose, also have to suffix a goroutine ID
> > > > to a
> > > > goroutine's name, since calling a function that contained
> > > > goroutines
> > > > repeatedly would result in multiple instances of each goroutine.
> > > >
> > > >
> > > > On Fri, 23 Nov 2018 at 22:36,  wrote:
> > > >
> > > > >
> &

Re: [go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

[Russtopia]

Interesting, thank you. I hadn't seen that. As you also said (while I was
still composing this) I wasn't proposing that one be able to read the name,
just set it.

Oh drat, I suppose my idea of adding one indirect function call to launch
each goroutine still loses the closure-like ability to access the caller's
environment though.

I always find Go's careful choice of minimalism to be brilliant -- no more
than is required, yet enough to be a joy to use. Yet this seems a bit of an
omission. Oh well.


On Sun, 25 Nov 2018 at 16:17, Bruno Albuquerque  wrote:

> Terra os 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 the goroutines, in stack traces, source
>> code, or in code visualization tools such as graphviz diagrams.
>>
>> What does that goroutine actually *do*? Is it a worker for some specific
>> purpose, does it read from stdin and forward to a pty/socket, does it wait
>> for data on some channel, does it sleep until a particular event occurs and
>> then reboot the box ... ? 'EnclosingFunc$1', 'EnclosingFunc$2' aren't very
>> useful names for documentation and the current Go syntax allows no
>> specification of this by naming the goroutine itself, short of moving it
>> completely out of the scope of the enclosing named function, and losing the
>> benefits of a closure.
>>
>> I guess what I'm getting at is that goroutines can't be named for what
>> they *mean* or *do*. Comments can of course explain this within the source
>> code, but I think there would be a concrete benefit to defining a
>> convention for comment-tagging goroutines, in provide this foothold for
>> external documentation tools; or, perhaps even better, a way to actually
>> name goroutines like how GCC allows named, nested functions. This could
>> even improve the readability of stack traces could it not?
>>
>> I've already devised a 'comment above each goroutine' hack, plus a
>> post-processing tool (basically a sed script) to massage the output of the
>> graphviz 'dot' data, where I place info above each goroutine so it can be
>> renamed in the output diagram. That addresses the naming issue within
>> graphviz diagrams for me, for now.
>>
>>
>> On Sun, 25 Nov 2018 at 15:28, Dan Kortschak <
>> dan.kortsc...@adelaide.edu.au> wrote:
>>
>>> That package doesn't introspect on running code, so a goroutine name is
>>> not necessary. go-callvis 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/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 graphviz, but rather a lack of support
>>> > for
>>> > naming goroutines within the language itself as goroutines are also
>>> > 'unnamed' in this sense within stack traces. It would aid in
>>> > understanding
>>> > the purpose of goroutines within a structure diagram if goroutines
>>> > could be
>>> > named somehow.
>>> >
>>> > I was hoping there was a way within Go to give goroutines meaningful
>>> > names
>>> > in such a way that graphviz-like tools could pick up on it and make
>>> > meaningful annotations.
>>> >
>>> > The runtime would, I suppose, also have to suffix a goroutine ID to a
>>> > goroutine's name, since calling a function that contained goroutines
>>> > repeatedly would result in multiple instances of each goroutine.
>>> >
>>> >
>>> > On Fri, 23 Nov 2018 at 22:36,  wrote:
>>> >
>>> > >
>>> > > Debugging. For example, if I have a deadlocked request I might want
>>> > > to
>>> > > attach with a debugger and find where exactly it's stuck.
>>> > >
>>> > > Right now this is complicated, you have to examine stacks of all
>>> > > goroutines to find the correct one.
>>> > >
>>> > > On Friday, November 23, 2018 at 9:24:42 PM UTC-8, Andrei Avram
>>> > > wrote:
>>>

Re: [go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

[Russtopia]

Hmm. Just after posting, of course, this occurred to me: goroutines are, I
guess, 'lambda functions', which are usually assumed to be anonymous. So
perhaps I'm asking for an abomination -- a 'named lambda function'. :)

For purposes of documentation vis-à-vis things like graphviz, I guess a
layer of indirection might be all that's required, eg.

func DispatcherFunc() {
  ...
  spawnWorkerA()
  ...
  spawnChannelWatcher()
  ...
}

func spawnWorkerA() {
  go func() { ... }()
}

func spawnChannelWatcher() {
  go func() { ... }()
}

Now one will get semantically meaningful 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 getting at -- it doesn't give a
> semantically meaningful name to the goroutines, in stack traces, source
> code, or in code visualization tools such as graphviz diagrams.
>
> What does that goroutine actually *do*? Is it a worker for some specific
> purpose, does it read from stdin and forward to a pty/socket, does it wait
> for data on some channel, does it sleep until a particular event occurs and
> then reboot the box ... ? 'EnclosingFunc$1', 'EnclosingFunc$2' aren't very
> useful names for documentation and the current Go syntax allows no
> specification of this by naming the goroutine itself, short of moving it
> completely out of the scope of the enclosing named function, and losing the
> benefits of a closure.
>
> I guess what I'm getting at is that goroutines can't be named for what
> they *mean* or *do*. Comments can of course explain this within the source
> code, but I think there would be a concrete benefit to defining a
> convention for comment-tagging goroutines, in provide this foothold for
> external documentation tools; or, perhaps even better, a way to actually
> name goroutines like how GCC allows named, nested functions. This could
> even improve the readability of stack traces could it not?
>
> I've already devised a 'comment above each goroutine' hack, plus a
> post-processing tool (basically a sed script) to massage the output of the
> graphviz 'dot' data, where I place info above each goroutine so it can be
> renamed in the output diagram. That addresses the naming issue within
> graphviz diagrams for me, for now.
>
>
> On Sun, 25 Nov 2018 at 15:28, Dan Kortschak 
> wrote:
>
>> That package doesn't introspect on running code, so a goroutine name is
>> not necessary. go-callvis 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/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 graphviz, but rather a lack of support
>> > for
>> > naming goroutines within the language itself as goroutines are also
>> > 'unnamed' in this sense within stack traces. It would aid in
>> > understanding
>> > the purpose of goroutines within a structure diagram if goroutines
>> > could be
>> > named somehow.
>> >
>> > I was hoping there was a way within Go to give goroutines meaningful
>> > names
>> > in such a way that graphviz-like tools could pick up on it and make
>> > meaningful annotations.
>> >
>> > The runtime would, I suppose, also have to suffix a goroutine ID to a
>> > goroutine's name, since calling a function that contained goroutines
>> > repeatedly would result in multiple instances of each goroutine.
>> >
>> >
>> > On Fri, 23 Nov 2018 at 22:36,  wrote:
>> >
>> > >
>> > > Debugging. For example, if I have a deadlocked request I might want
>> > > to
>> > > attach with a debugger and find where exactly it's stuck.
>> > >
>> > > Right now this is complicated, you have to examine stacks of all
>> > > goroutines to find the correct one.
>> > >
>> > > On Friday, November 23, 2018 at 9:24:42 PM UTC-8, Andrei Avram
>> > > wrote:
>> > > >
>> > > >
>> > > > What's the need for this?
>> > > --
>> > > 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.
>> > > For more options, visit https://groups.google.com/d/optout.
>> > >
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

[Russtopia]

That still doesn't address what I'm getting at -- it doesn't give a
semantically meaningful name to the goroutines, in stack traces, source
code, or in code visualization tools such as graphviz diagrams.

What does that goroutine actually *do*? Is it a worker for some specific
purpose, does it read from stdin and forward to a pty/socket, does it wait
for data on some channel, does it sleep until a particular event occurs and
then reboot the box ... ? 'EnclosingFunc$1', 'EnclosingFunc$2' aren't very
useful names for documentation and the current Go syntax allows no
specification of this by naming the goroutine itself, short of moving it
completely out of the scope of the enclosing named function, and losing the
benefits of a closure.

I guess what I'm getting at is that goroutines can't be named for what they
*mean* or *do*. Comments can of course explain this within the source code,
but I think there would be a concrete benefit to defining a convention for
comment-tagging goroutines, in provide this foothold for external
documentation tools; or, perhaps even better, a way to actually name
goroutines like how GCC allows named, nested functions. This could even
improve the readability of stack traces could it not?

I've already devised a 'comment above each goroutine' hack, plus a
post-processing tool (basically a sed script) to massage the output of the
graphviz 'dot' data, where I place info above each goroutine so it can be
renamed in the output diagram. That addresses the naming issue within
graphviz diagrams for me, for now.


On Sun, 25 Nov 2018 at 15:28, Dan Kortschak 
wrote:

> That package doesn't introspect on running code, so a goroutine name is
> not necessary. go-callvis 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/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 graphviz, but rather a lack of support
> > for
> > naming goroutines within the language itself as goroutines are also
> > 'unnamed' in this sense within stack traces. It would aid in
> > understanding
> > the purpose of goroutines within a structure diagram if goroutines
> > could be
> > named somehow.
> >
> > I was hoping there was a way within Go to give goroutines meaningful
> > names
> > in such a way that graphviz-like tools could pick up on it and make
> > meaningful annotations.
> >
> > The runtime would, I suppose, also have to suffix a goroutine ID to a
> > goroutine's name, since calling a function that contained goroutines
> > repeatedly would result in multiple instances of each goroutine.
> >
> >
> > On Fri, 23 Nov 2018 at 22:36,  wrote:
> >
> > >
> > > Debugging. For example, if I have a deadlocked request I might want
> > > to
> > > attach with a debugger and find where exactly it's stuck.
> > >
> > > Right now this is complicated, you have to examine stacks of all
> > > goroutines to find the correct one.
> > >
> > > On Friday, November 23, 2018 at 9:24:42 PM UTC-8, Andrei Avram
> > > wrote:
> > > >
> > > >
> > > > What's the need for this?
> > > --
> > > 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.
> > > For more options, visit https://groups.google.com/d/optout.
> > >
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

[Russtopia]

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 graphviz, but rather a lack of support for
naming goroutines within the language itself as goroutines are also
'unnamed' in this sense within stack traces. It would aid in understanding
the purpose of goroutines within a structure diagram if goroutines could be
named somehow.

I was hoping there was a way within Go to give goroutines meaningful names
in such a way that graphviz-like tools could pick up on it and make
meaningful annotations.

The runtime would, I suppose, also have to suffix a goroutine ID to a
goroutine's name, since calling a function that contained goroutines
repeatedly would result in multiple instances of each goroutine.


On Fri, 23 Nov 2018 at 22:36,  wrote:

> Debugging. For example, if I have a deadlocked request I might want to
> attach with a debugger and find where exactly it's stuck.
>
> Right now this is complicated, you have to examine stacks of all
> goroutines to find the correct one.
>
> On Friday, November 23, 2018 at 9:24:42 PM UTC-8, Andrei Avram wrote:
>>
>> What's the need for this?
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

[Russtopia]

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 naming a goroutine, or nested funcs that are
*not* goroutines, at all?

I think this would be a nice feature for two reasons:

1. It is, of course, possible to just move the goroutine out into an
outside, named function, but then one must manually identify, declare and
pass all the parameters the goroutine might otherwise automatically capture
from its parent scope(s) when refactoring it. One loses the nice
closure-ish syntax of goroutines;

2. It would allow tools such as graphviz to more easily generate diagrams
that can name goroutines something meaningful other than "func$1" for a
goroutine launched within "func".

-Russ

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The benefits and costs of writing a POSIX kernel in a high-level language

[Russtopia]

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%
free of C could be a reality. Wouldn't that be amazing?


On Mon, 8 Oct 2018 at 16:17, andrey mirtchovski 
wrote:

> I do not think this has been shared yet, please accept my apologies if
> this is a repeat.
>
> https://www.usenix.org/conference/osdi18/presentation/cutler
>
> The paper contributes Biscuit, a kernel written in Go that implements
> enough of POSIX (virtual memory, mmap, TCP/IP sockets, a logging file
> system, poll, etc.) to execute significant applications. Biscuit makes
> liberal use of Go's HLL features (closures, channels, maps,
> interfaces, garbage collected heap allocation), which subjectively
> made programming easier. The most challenging puzzle was handling the
> possibility of running out of kernel heap memory; Biscuit benefited
> from the analyzability of Go source to address this challenge.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.