[go-nuts] Re: Quick question about calling Set-Cookie twice in a row

[B Carr]

In my application, the most recent cookie value with the same name is 
returned on the next request.

On Tuesday, July 14, 2020 at 1:54:56 PM UTC-6, atd...@gmail.com wrote:
>
> Hello,
>
> As I am writing some tests, I was wondering what should be the correct 
> behavior when http.SetCookie is called twice with cookies of a same name 
> but different values.
>
> For example, what should a user-agent see as the cookie value and hence, 
> what should it return back to the server with the next request?
>
> https://play.golang.org/p/nYDmcFcd8Qj
>
> Many thanks!
>
>
>

-- 
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/442794c0-c906-4472-ba8a-6017a22e19e8o%40googlegroups.com.

[go-nuts] Re: Go Time #100 with Robert Griesemer and myself

[B Carr]

This was interesting. Thank you!

On Wednesday, September 25, 2019 at 5:14:51 PM UTC-6, Rob 'Commander' Pike 
wrote:
>
> It's now live: https://changelog.com/gotime/100 
> 
>
> -rob
>
>

-- 
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/8b009699-d0c2-40de-92d8-9d1fb44f47e2%40googlegroups.com.

Re: [go-nuts] Re: package-level structs vs package-level vars

[B Carr]

On Monday, August 5, 2019 at 9:33:08 AM UTC-6, burak serdar wrote:
>
> On Mon, Aug 5, 2019 at 9:20 AM B Carr > 
> wrote: 
> > 
> > Oh. I'm talking about env variables which a goroutine sets by using 
> os.Setenv() which to me implies OS env variables. Are those env variables 
> accessible by all goroutines regardless of which goroutine set the env 
> variable? Would such env variables be available to newer goroutines that 
> spin up? I think the answer to this is "Yes", based on a response I got to 
> another thread. 
>
> Those env variables belong to the process. All gorountines share them. 
> If you're setting env variables from goroutines, you might want to 
> think about thread safety of setenv.


Oh yes. I'm using a mutex.

Thank you.

-- 
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/7fd673ac-cc05-401d-ba6f-e07151fd6ab3%40googlegroups.com.

Re: [go-nuts] Re: package-level structs vs package-level vars

[B Carr]

On Monday, August 5, 2019 at 8:52:41 AM UTC-6, burak serdar wrote:
>
> On Mon, Aug 5, 2019 at 8:47 AM B Carr > 
> wrote: 
> > 
> > Is it safe to say that environment variables (accessible to all 
> goroutines) also live in the data segment? 
>
> No. 
>
> When you say "environment variables", do you mean OS env variables, or 
> the variables visible to a goroutine? 
>
> If you're talking about the variables visible to a goroutine, where 
> the variable lives depends on how it is declared and allocated. 
>
> If the variable is allocated at compile time (like a global var/struct 
> initialized with a literal) it lives in data segment. 
>
> If the variable is allocated dynamically using new(), or it is 
> declared in a function and it escapes, it lives on the heap. 
>

Oh. I'm talking about env variables which a goroutine sets by using 
os.Setenv() which to me implies OS env variables. Are those env variables 
accessible by all goroutines regardless of which goroutine set the env 
variable? Would such env variables be available to newer goroutines that 
spin up? I think the answer to this is "Yes", based on a response I got to 
another thread.

I'm apparently being too black/white in my thinking about where things get 
put into memory and your explanations are helping to get my mind right.

-- 
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/e064b3a9-19f1-48ca-8fab-e438a737b889%40googlegroups.com.

[go-nuts] Re: package-level structs vs package-level vars

[B Carr]

Is it safe to say that environment variables (accessible to all goroutines) 
also live in the data segment?

-- 
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/01cea3eb-8f87-4ee3-a306-6641697c8a48%40googlegroups.com.

Re: [go-nuts] package-level structs vs package-level vars

[B Carr]

Would that be where structs live as well?

On Sunday, August 4, 2019 at 6:25:55 PM UTC-6, Robert Engels wrote:
>
> I’m pretty sure they will be in the data section, for non 
> interface/pointer types which is even better than the stack.


>

-- 
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/96d1c669-a65c-48ad-9ac1-17663e20c416%40googlegroups.com.

[go-nuts] package-level structs vs package-level vars

[B Carr]

Concept observation. Could use some amplification from the congregants, 
please...

I'm learning about Go.

My webserver program had lots of package level vars and only two, small 
structs. I set a dozen webpages to refresh very busy data calculations 
every 6 seconds. Over the course of an hour, looking at the pprof output 
for 'alloc' & 'heapAlloc' it looked like the GC was very busy and collected 
>6 GiB of stuff. It looked like it would have continued increasing into 
infinity. Even during that time, the GC rarely went over 10ms active times.

I got rid of all the package level vars and put them inside of structs and 
pass around the struct values to the functions as needed. Using the same 
test setup above, I set a dozen webpages to refresh very busy data 
calculations every 6 seconds. Over the course of an hour, looking at the 
pprof output for 'alloc' & 'heapAlloc' it looked like the GC just loafed 
along and collected <10 MiB of stuff. And that number was pretty level. The 
GC was showing mostly zero nanosecond times.

I didn't do any timing testing, but the speediness of all the webpages felt 
about the same in both test cases.

I have a notion about what I'm seeing. Anyone care to increase my level of 
understanding? Are my interpretations about what pprof is showing me 
accurate?

(ps - a big thank you to Burak Serdar who, in a previous thread, showed me 
something I hadn't considered and put me on the path to making my webserver 
program successfully concurrent!)

TIA,

Bucky

-- 
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/fb49d5bb-f795-4ca3-af5c-d883aabcf1af%40googlegroups.com.

[go-nuts] Re: go question about goroutines

[B Carr]

I think the answer to this is No and Yes.

On Wednesday, July 24, 2019 at 2:18:07 PM UTC-6, joe mcguckin wrote:
>
>
> If I have multiple go applications running, do they share the same 
> runtime? Or does each one have it's own runtime and set of threads, etc.
>

-- 
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/e774facb-27fc-4131-9e8c-6e510ab2b7f9%40googlegroups.com.

Re: [go-nuts] Go http server

[B Carr]

On Wednesday, July 24, 2019 at 2:17:58 PM UTC-6, Burak Serdar wrote:
>
> On Wed, Jul 24, 2019 at 1:36 PM B Carr > 
> wrote: 
> > 
> > I'm mostly interested in the degree of insulation one goroutine has from 
> another. My extensive reading indicates that absent a goroutine 
> intentionally communicating outside of itself (via a channel), that 
> whatever it does (short of making changes to globally accessible resources 
> such as a database or map) can't be seen by other goroutines. Is that a 
> correct assessment? 
>
> Not precisely. The shared resource doesn't have to be global, but 
> simply accessible from more than one goroutine. 
>
> i:=1 
> go func() { do something with i } () 
> go func() { do something else with i} () 
>
> The variable i is not global but shared between three goroutines (the 
> two, and the one that spawned the other two). Any modification done to 
> i by one goroutine has no guarantees to being seen by others unless 
> there is synchronization. 
>

A, a subtle misunderstanding on my part. Thank you.
 

-- 
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/fb1de7ea-d4f8-416b-8936-61b6cea9388f%40googlegroups.com.

[go-nuts] Goroutines & ENV

[B Carr]

Basic question: Do goroutines all share the same ENV?

-- 
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/b416718d-ed90-49f8-a07b-f7467cc667cc%40googlegroups.com.

Re: [go-nuts] Go http server

[B Carr]

On Wednesday, July 24, 2019 at 1:11:31 PM UTC-6, Burak Serdar wrote:
>
> On Wed, Jul 24, 2019 at 12:37 PM B Carr > 
> wrote: 
> > 
> > Am I correct in thinking that the unique goroutine is active for the 
> entirety of the connection session? Everything between the "goroutine spins 
> up" and "goroutine 
> > spins down" is handled in the one, single goroutine? That the 
> concurrency is automatic at that point? 
>
> If that handler goroutine doesn't start others, then that's correct. I 
> don't understand what you mean by "concurrency is automatic". 
>

Thank you. What I meant by the concurrency comment is that the http server 
takes care of allowing multiple, same-webpage sessions to occur 
simultaneously via goroutines and that I don't have to include any 'go 
func(...)' lines in my code for that to happen. And I don't have the 
handler goroutine starting up any others.

I'm mostly interested in the degree of insulation one goroutine has from 
another. My extensive reading indicates that absent a goroutine 
intentionally communicating outside of itself (via a channel), that 
whatever it does (short of making changes to globally accessible resources 
such as a database or map) can't be seen by other goroutines. Is that a 
correct assessment?

My basic problem is that I'm coming from a Visual Basic background and 
unlearning bad programming habits is causing me to stumble a lot. Go is far 
superior to Visual Basic and I'm having fun converting a VB app into a Go 
webserver app.

But I'm learning a lot too, and so very much appreciate your evaluations. 
Thank you.

-- 
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/619fd324-b728-48d9-b4e0-68d42e203645%40googlegroups.com.

[go-nuts] Go http server

[B Carr]

Neophyte here.

Concept help again, please. This all relates to Go.


http server waiting for requests...

http GET request comes in

... goroutine spins up

handler calls function which may call another function which ultimately 
services the GET request by providing a response (webpage) then returns.

goroutine spins down ...

http server waiting for requests...


Am I correct in thinking that the unique goroutine is active for the 
entirety of the connection session? Everything between the "goroutine spins 
up" and "goroutine
spins down" is handled in the one, single goroutine? That the concurrency 
is automatic at that point?

To carry the idea further...

Two (or a thousand) requests for the same webpage come in at about the same 
time. The http server spins up two (or a thousand) goroutines that are all 
active *and* insulated from each other for the duration of the GET-Response 
cycle.

Am I good in my thinking so far?

-- 
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/ac35f488-e846-418a-888b-2e2ddf0e1992%40googlegroups.com.

[go-nuts] Re: Build issues on FreeBSD ZoF "unexpected stale targets"

[B Carr]

What does this part mean? "...with the ZFS rebased to ZFS on Linux..."


On Friday, July 19, 2019 at 1:37:02 PM UTC-6, mat...@gmail.com wrote:
>
> I'm not sure where to ask this since this isn't actually a Go bug. Go 
> 1.12, 1.1, etc build fine on FreeBSD with ZFS in base. However, with the 
> ZFS rebased to ZFS on Linux I'm seeing issues that I can only reproduce 
> building Go.
>

-- 
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/fb3ca79e-cd21-4b4f-ac6c-4e608825d26e%40googlegroups.com.

[go-nuts] Re: About the Google logo on the new Go website

[B Carr]

Google has spent and is spending 10s of millions of $$$ on the development 
of Go and all while continuously giving it away without strings attached.

And people have so much free time they complain about a tiny symbol in the 
upper left corner of the golang.org website?

Thank you to the Go Developers, Go Contributors and Google!

-- 
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/c8ea5740-bd29-41d5-92cc-3323a1fa08cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go NaCl and C NaCl/libsodium

[B Carr]

Okay, I think I understand now. Ian intimates that support for "native 
client" is going away after Go v1.13. But support for the crypto/nacl 
package is remaining.

Have I got that right? Thanks for explaining.

-- 
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/1c33768e-0ff7-4ebc-9d32-0ec25a67221a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go NaCl and C NaCl/libsodium

[B Carr]

Ugh. Why is that? What is the recommended replacement?


On Friday, July 12, 2019 at 10:34:10 PM UTC-6, Ian Lance Taylor wrote:
>
>
> I'm just replying to make sure that you know 
> that we are dropping NaCl support from Go after the 1.13 release. 
>
> 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/14e980b1-9c0e-4bfd-aed4-bfc3fdcb4476%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: net/http and the GC

[B Carr]

On Monday, July 8, 2019 at 1:01:26 PM UTC-6, Burak Serdar wrote:
>
>
> > I'll need to study this a bit more. Can you give me a pointer? 
>
> I don't know really, other than the obvious ones like: 
>
> http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/ 
> https://golang.org/doc/  -> there's sections on concurrency patterns, 
> http servers, etc. 
>

Thanks for that.
 

>
> The most difficult and crucial thing with go is to change the way you 
> think about concurrency. For years I wrote programs in Java, and when 
> I started working with go, I looked for thread pools and thread local 
> variables. Learning to live without them was refreshing. 
>

Since I'm coming to Go with zero background in concurrency there is nothing 
contaminating me. Fortunately...

-- 
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/f658e6c9-7b73-4f25-a7db-4c5a95df79bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: net/http and the GC

[B Carr]

Thank you, that means I'm thinking correctly about this and need to keep 
plugging along.

>>"the total number of concurrent requests you can handle depends on how 
you handle your GET requests."

I'll need to study this a bit more. Can you give me a pointer?

-- 
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/052ac63e-259e-4e40-968f-0c5f66800b1b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] net/http and the GC

[B Carr]

Gophers -

Trying to learn Go (I'm a hobbyist) and have a fundamental net/http 
question. I have a web server running with a web page set to refresh every 
2 seconds. I have 3 different browsers making webserver GET requests. Each 
browser's refresh is spinning up a new goroutine on the server, right? And 
that leaves the preceding goroutine started by that browser's GET 
dead/unused going forward, right?

I'm watching the memory usage of the webserver and it is steadily 
increasing though it does seem to level off after a while.

Is the GC taking care of removing the unused goroutines and that is why I'm 
seeing the memory use increases start to level off? If I stop all the 
browsers would the GC gobble up all the now-useless goroutines and memory 
use for the webserver would drop back to nominal? At one point when I was 
tracking down one race condition (out of 839 reported), the race output 
showed "goroutine #29316". Good grief! I fixed all the race conditions 
reported.

If I set the page refreshes to a larger number, such as 5 minutes, would 
the GC gobble up the unused goroutines fast enough that I wouldn't see much 
increase in memory use?

Or am I thinking about this all wrong?

TIA,

Bucky

-- 
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/d2903306-e0b0-4e7e-a035-ff14b3c64c52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Cross-Compile Windows 10 -> FreeBSD

[B Carr]

Thank you. Probably too hard for me.

On Tuesday, June 11, 2019 at 10:09:49 PM UTC-6, Tamás Gulácsi wrote:
>
> Not hopeless, just hard. You need a cross-C-compiler, and use that.
>
> It's easier to compile on native en.
> But you can try github.com/karalabe/xgo if you have Docker.
>

-- 
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/6e7cc795-341b-4c9b-8bb9-7b388ae94aee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Cross-Compile Windows 10 -> FreeBSD

[B Carr]

To reply to myself, I just found this comment under ADDENDUM:

"Cgo has issues when cross compiling. If you depend on cgo then you’re 
probably going to be better off building on the native platforms. The go 
tool will disable cgo support by default. To explicitly enable cgo, set 
CGO_ENABLED=1."

@ https://spf13.com/post/cross-compiling-go/

Does this mean cross-compiling with Go when cgo is required is hopeless?

-- 
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/e61381f8-563f-4474-b8ca-7d0ace40784c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Cross-Compile Windows 10 -> FreeBSD

[B Carr]

Newb here. I'm in over my head. Using a Win10/amd64 PowerShell with Go 
v1.12.6. Trying to cross-compile
to FreeBSD/amd64. go env = GOARCH=amd64 & GOOS=freebsd. Source includes 
calls to SQLite3. Compiles
without errors.

Resulting binary fails on FreeBSD with: "Can't connect to the SQLite DB 
Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work."

Added CGO_ENABLED=1 to the go env.  Recompile fails to build a binary and 
yields this error stream:

"# runtime/cgo
_cgo_export.c:1:0: error: -fPIC ignored for target (all code is position 
independent) [-Werror]
 /* Code generated by cmd/cgo; DO NOT EDIT. */
 ^
cc1.exe: all warnings being treated as errors"

I have no idea what that means.

Same source compiled for the Win10 machine runs perfectly. If I copy the 
source code over to a
FreeBSD box with Go installed there and compile, it works fine. It is the 
cross-compilation that
doesn't seem to work.

This isn't a Go problem, it is something I'm not understanding about 
cross-compiling

Any thoughts?

-- 
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/ebe9fe0d-7727-40b9-bc53-a9d237faecf7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 1.8 port to FreeBSD/PowerPC64

[B Carr]

I'm wondering what you are trying to do as well. Go (latest version) is 
already available in the ports collection for FreeBSD. Installs just fine.


On Friday, May 31, 2019 at 7:54:55 PM UTC-6, Curtis Hamilton wrote:
>
> I’m porting Go 1.8 to FreeBSD/PowerPC64.  I’ve successfully built 
> go-FreeBSD-ppc64-bootstrap using go on FreeBSD/amd64.


> Can someone help?

-- 
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/9c24b6b2-8d99-4f5a-a91a-7b104883c958%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Interesting public commentary on Go...

[B Carr]

I'm a hobbyist and make no money on the Go projects I write. This article 
seems a bit over-the-top, particularly Fred Fnord's comment. Doesn't Linus 
Torvalds have a stranglehold on the Linux kernel? Yet Linux flourishes.

Rather than complaining about Google (via Go) why don't these folks simply 
switch to Rust or some other language and press on?

-- 
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/c837432a-16a1-4e09-8435-0e901c07de1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.