Re: [go-nuts] How to find optimal value for GOGC?

[Wojciech S. Czarnecki]

On Thu, 16 Nov 2017 09:26:05 -0800 (PST)
Christian LeMoussel  wrote:

>  Go has the GOGC variable, that can also be controlled with the 
> SetGCPercent function in the runtime/debug package.

> Is it possible to find the optimal value of GOGC to get the most op / s per 
> report to the number of cores?

Yes it is possible. Please read
https://blog.cloudflare.com/go-dont-collect-my-garbage/
for 'howto' tips.

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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: How to find optimal value for GOGC?

[Christian LeMoussel]

Interesting article. However, it does not describe the script/bench to find 
the best value, from 100 to 20,000, in increments of 100. 

-- 
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] acme, letsencrypt and different HTTPS ports

[Shulhan]

On Thu, 16 Nov 2017 20:59:16 -0800 (PST)
Sankar  wrote:

> Hi
> 
> I have an EC2 vm where I want to run two go https servers on
> different ports.
> 
> I am using letsencrypt for the certificates and the code is like:
> 
> server1.go:
> log.Fatal(http.Serve(autocert.NewListener("api1.example.com"),
> http.DefaultServeMux)) server2.go:
> log.Fatal(http.Serve(autocert.NewListener("api2.example.com"),
> http.DefaultServeMux))
> 
> I want api1 to listen on port 443 and want api2 to listed on port
> 8080. Is it possible to achieve this via autocert at all ? If not,
> are there any other hacks to get multiple ports exposed from the same
> machine using letsencrypt ? I am deploying server1.go manually (via a
> systemd script) and server2 via a docker container, if it matters.
> 
> Any help ?
> 
> Thanks.
> 

Usually people use proxy in the front, and direct the traffic based on
hostname. The proxy will listen on port 80 and 443 with valid
certificate, and your backend is listened on other non root port (e.g.
9001 for api1 and 9002 for api2).

Upon receiving the incoming connection proxy will check the hostname,
if hostname is `api1.example.com`, proxy will forward the traffic to
backend at port 9001.
If hostname is `api2.example.com`, proxy will forward the traffic to
backend at port 9002.

 Your server
+--+   +-+   (1)  +---+
| internet | <===> | proxy   | <> | api1:9001 |
+--+   +-++---+
   ^^
   || +---+
   +> | api2:9002 |
  +---+

Some noticeable proxy application: haproxy.

--
Shulhan

-- 
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] Large number of goroutines on PowerPC

[Conrado PLG]

Hi,

I'm working on a software for a 32-bit PowerPC processor. Since there is no 
Go support for it, I'm using gccgo. However, I've noticed that it's not 
possible to use a large number of goroutines since each one takes around 2 
MB of memory. From what I understand, this is the stack space reserved for 
each goroutine, and it's large because gccgo does not support split stack 
for non-x86 processors.

My questions are:

- Is there a way to reduce the stack usage of goroutines (even if it 
requires recompiling gccgo)?

- How difficult would it be to port Go to 32-bit PowerPC (Linux)? Could 
someone give a high-level overview of what would need to be changed (or is 
there an overview somewhere)?

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

[go-nuts] Re: [crypto/aes] How do I specify an initialization vector?

[Chetan Gowda]

Thank you, Conrado. That indeed fixed it.

-- 
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: test debugging woes

[Alex Buchanan]

Some ideas:

- I assume the code isn't public? If it is, you might share it
- Are you running `go test -v` for verbose logging?
- Try fmt.Printf
- Try adding printing lines at points down the stack leading up to the 
point you think is failing, to make sure the code is actually running.
- Put a log line before each return in said function

On Thursday, November 16, 2017 at 10:54:53 PM UTC-8, Tom Denton wrote:
>
> Hello!
>
> I'm debugging a strange test failure, and with the magic of printf 
> debugging (t.Logf) have been adding bits to the test itself to get a sense 
> of what's wrong. The bad bahaviour is happening deep in library code, in a 
> function which returns nil for one of six reasons... I threw some 
> log.Fatalf() statements in that code in my citc to see what breaks, but 
> it's not showing up in the test logs at all.  Probably I'm making bad life 
> decisions; what, go community, am I supposed to be doing here?
>

-- 
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] context.C and context.BG

[Alex Buchanan]

I don't have numbers, but context must be one of the most commonly used 
imports/types in my code. It shows up many function signatures. We try to 
use it for all cancelation.

Would it make sense to add an alias "C" to the type "Context"? And maybe 
"BG" for Background()? 

Also, is there a specific reason Background is a function and not a value?

Cheers,
Alex

-- 
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: invitation to gophers.slack.com

[Jonathan Yu]

Go here to request an invite: https://invite.slack.golangbridge.org/

On Fri, Nov 17, 2017 at 7:16 AM, Matteo G.  wrote:

> Hi, I don't understood how I can sign up to ghopers.slack.com. Some
> suggestion?
>
> --
> 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.
>



-- 
Jonathan Yu / *@jawnsy* on LinkedIn ,
Twitter , GitHub ,
Facebook 
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options

 (HBR)

-- 
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] Easy access to #golang

[Sam Whited]

Hi all,

I don't like signing up for accounts, or having to jump through hoops
(even if they're relatively straight forward hoops) to get an invite to
something that should just be public. Also, some people seem to like web
clients, so here's a quick and easy way to access the #golang channel on
Freenode:

https://gopher.chat/

I hope you find it useful.

—Sam

-- 
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] fatal error: sweep increased allocation count, go1.9.x

[matthewjuran]

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

I'll try to put together an easier failing case with less code and without 
the database. Thanks for the help.

Matt

On Thursday, November 16, 2017 at 3:52:56 PM UTC-6, Ian Lance Taylor wrote:
>
> On Thu, Nov 16, 2017 at 11:28 AM,   
> wrote: 
> > 
> > I've encountered a crash with the signature "fatal error: sweep 
> increased 
> > allocation count" that only appears for me in the go.1.9.x series, 
> testing 
> > on linux/amd64. The memory problem appears to be triggered in this 
> function: 
>
> Thanks for the report.  Please open an issue for this at 
> https://golang.org/issue.  Thanks. 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Large number of goroutines on PowerPC

[Ian Lance Taylor]

On Fri, Nov 17, 2017 at 3:31 AM, Conrado PLG  wrote:
>
> I'm working on a software for a 32-bit PowerPC processor. Since there is no
> Go support for it, I'm using gccgo. However, I've noticed that it's not
> possible to use a large number of goroutines since each one takes around 2
> MB of memory. From what I understand, this is the stack space reserved for
> each goroutine, and it's large because gccgo does not support split stack
> for non-x86 processors.
>
> My questions are:
>
> - Is there a way to reduce the stack usage of goroutines (even if it
> requires recompiling gccgo)?

Edit StackMin (for the non-split-stack case) in libgo/runtime/proc.c
and rebuild libgo.

Note that GCC does support split stacks for 64-bit PPC.  I don't know
how difficult it would be to add support for 32-bit PPC.


> - How difficult would it be to port Go to 32-bit PowerPC (Linux)? Could
> someone give a high-level overview of what would need to be changed (or is
> there an overview somewhere)?

It probably wouldn't be too hard for someone familiar with PPC32 and
PPC64 as used on GNU/Linux.  Basically look for every file in the Go
distribution with "ppc64" in the name, and plan to write a plan "ppc"
version.

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

[go-nuts] Should net.Conn transform function retain the original data segmentation?

[Xiaoyi Shi]

Hi all,

To clarify, a net.Conn transform function transforms data write to/read 
from a connection, an example is as follow:

type TransformedConn struct {
  net.Conn}

func (c *TransformedConn) Read(p []byte) (int, error) {
  n, err := c.Conn.Read(p)
  transform(p)
  return n, err}

func (c *TransformedConn) Write(p []byte) (int, error) {
  t := append([]byte{}, p...) // as `p` must not be modified per io.Writer doc
  transform(t)
  return c.Conn.Write(t)}

Similarly, crypto/cipher.StreamReader and crypto/cipher.StreamWriter perform 
a similar operation.

As required by io.Writer.Write(), it cannot modify the input buffer. In 
case the size of the buffer is huge, creating a buffer of the same size 
will be very expensive. So I'm wondering if it's ok for such transform 
function to write data out in smaller chunks, to allow us using a smaller 
scratch space?

I've found such chunking technique will cause some program to fail, 
especially the ones use io.ReadFull() and io.ReadAtLeast(). Because they 
implicitly expect that the data to arrive will from a single read() call.

Could someone point me a doc or a spec on how to write such transform 
functions?

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

[go-nuts] Re: test debugging woes

[deparker]

You could try using Delve (https://github.com/derekparker/delve) to 
actually step through and inspect the process during execution to avoid 
having to put print statements everywhere. Similar to the Go command, you 
can run `dlv test` and begin stepping through your test binary.

On Thursday, November 16, 2017 at 10:54:53 PM UTC-8, Tom Denton wrote:
>
> Hello!
>
> I'm debugging a strange test failure, and with the magic of printf 
> debugging (t.Logf) have been adding bits to the test itself to get a sense 
> of what's wrong. The bad bahaviour is happening deep in library code, in a 
> function which returns nil for one of six reasons... I threw some 
> log.Fatalf() statements in that code in my citc to see what breaks, but 
> it's not showing up in the test logs at all.  Probably I'm making bad life 
> decisions; what, go community, am I supposed to be doing here?
>

-- 
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] test debugging woes

[DV]

I wish I could help you, but your description of the problem could not be more 
vague.  Your post can be rewritten as "problem pls help". 

What library is this? Is it on GitHub? Can we look at it? What section of code 
is returning nil? Is nil the problem? Or is there a panic? What's your code 
look like? How are you invoking 'go test'? What's a "citc"? That's just some of 
the questions that sprang into my mind in the first 5 seconds of reading your 
question. 

-- 
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] Flagging lazy-loaded fields as being unsafe to access directly

[Traun Leyden]

I'm trying to figure out a way to best signal to other developers 
maintaining a single package that a field is unsafe to access directly.  In 
this case, it's being lazily loaded, and the only way to ensure it will be 
properly loaded is to access the method wrapper rather than directly 
accessing the field.

For example, see this code :

type foo struct {
   bar string
}

// Method wrapper that does lazy-loading
func (f *foo) getBar() string {
if f.bar == "" {
// lazy-load this from a database or some other expensive call
f.bar = "bar"
}
return f.bar
}

func main() {
f := foo{}
fmt.Printf("f.bar directly: %v\n", f.bar) 
fmt.Printf("f.bar lazy-loaded: %v\n", f.getBar()) 
}


If you access the field directly, you get an empty value.  If you call the 
method wrapper, you get the intended value.

I believe the official answer is just "do the right thing" since you are 
within the package boundaries and have full control.  And I'm pretty sure 
the language doesn't provide anything here.  

But what I'm wondering -- are there any common conventions or workarounds 
to avoid this pitfall?  So far the only idea I've been able to come up with 
is to use underscores and/or comments to clearly mark the field as being 
unsafe to access directly:

type foo struct {
   *_bar* string  *// You probably want to use getBar() since this is 
lazily loaded an unsafe to access directly.*
}



-- 
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] Google Cloud Golang SDK authentication

[SALMAN AHMED]

I am trying to automate the VM and Network resource creation using GCD 
Client API. I do not want to use Google OAuth as the user has to generate 
token every time. I used AWS SDK and it can be invoked by simply using 
AccessKey and Secret Key. Is there any authentication method that does 
not need user's interaction? I saw the Service Account authentication 
method but could not find any detailed example. Will it work for GCD 
compute API? and I saw that Service Account is based on environment 
variable and my app could have multiple users with different accounts.

-- 
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: Flagging lazy-loaded fields as being unsafe to access directly

[Nicholas Hanley]

In Go, lowercase identifiers are not visible outside the package in which 
they are defined (ref: Exported identifiers 
). Your example declares 
foo in the main package but I assume your real code would be in its own 
package. What you can do is export Foo and GetBar, but leave the bar field 
unexported.

Your code would look something like this:
main.go
package main

import (
"fmt"

"example.com/baz"
)

func main() {
f := baz.Foo{}
fmt.Printf("f.bar lazy-loaded: %v\n", f.GetBar())
}

example.com/baz/foo.go
package baz

type Foo struct {
bar string
}

// Method wrapper that does lazy-loading
func (f *Foo) GetBar() string {
if f.bar == "" {
// lazy-load this from a database or some other expensive call
f.bar = "bar"
}
return f.bar
}


On Friday, November 17, 2017 at 4:00:27 PM UTC-5, Traun Leyden wrote:
>
>
>
> I'm trying to figure out a way to best signal to other developers 
> maintaining a single package that a field is unsafe to access directly.  In 
> this case, it's being lazily loaded, and the only way to ensure it will be 
> properly loaded is to access the method wrapper rather than directly 
> accessing the field.
>
> For example, see this code :
>
> type foo struct {
>bar string
> }
>
> // Method wrapper that does lazy-loading
> func (f *foo) getBar() string {
> if f.bar == "" {
> // lazy-load this from a database or some other expensive call
> f.bar = "bar"
> }
> return f.bar
> }
>
> func main() {
> f := foo{}
> fmt.Printf("f.bar directly: %v\n", f.bar) 
> fmt.Printf("f.bar lazy-loaded: %v\n", f.getBar()) 
> }
>
>
> If you access the field directly, you get an empty value.  If you call the 
> method wrapper, you get the intended value.
>
> I believe the official answer is just "do the right thing" since you are 
> within the package boundaries and have full control.  And I'm pretty sure 
> the language doesn't provide anything here.  
>
> But what I'm wondering -- are there any common conventions or workarounds 
> to avoid this pitfall?  So far the only idea I've been able to come up with 
> is to use underscores and/or comments to clearly mark the field as being 
> unsafe to access directly:
>
> type foo struct {
>*_bar* string  *// You probably want to use getBar() since this is 
> lazily loaded an unsafe to access directly.*
> }
>
>
>
>

-- 
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] Automation of Compute VM and Network Resource Creation

[salmanbukhari512]

I am working on an application which creates VM's and Network Resources on 
GCD and other clouds. In AWS you can create resources using AccessKey and 
SecretKey. I don't want any interaction to Google's OAuth for the requests 
I send to create resources. What kind of authentication method should I 
use? I saw the service account authentication but could not find any 
working example which I could refer. Does Compute API supports that 
authentication method?

-- 
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] Bug report github.com/golang/glog

[Brian Kennedy]

For the flag "log_backtrace_at" the flag expects "" for an empty value when
calling Set(), but .String() will return ":0" when the value is empty. This
results in a different "emtpy" value being generated by String() than is
accepted by Set().

The following code will reproduce the issue.

*Output from process:*
Value: ":0"
Setting flag returned error: syntax error: expect file.go:234

*Code Snippet:*

package main

import (
  "flag"
  "fmt"

  "github.com/golang/glog"
)

func main() {
  flag.Parse()

  lba := flag.Lookup("log_backtrace_at")
  if lba == nil {
glog.Fatalf("Needs to depend on glog")
  }
  fmt.Printf("Value: \"%s\"\n", lba.Value.String())
  err := lba.Value.Set(lba.Value.String())
  if err != nil {
fmt.Printf("Setting flag returned error: %s\n", err)
  }
}

-- 
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: context.C and context.BG

[me via golang-nuts]

I've found a hint. Apparently, both context.TODO and context.Background 
share a common implementation but they need distinct addresses.

See https://golang.org/src/context/context.go#L168

So they cannot be constants because then they would not have an address. 
They cannot be variables because then you could modify them. Therefore the 
only solution left is to make them a function that returns a variable.

Then again, maybe you could make Background and TODO of an unexported type 
to prevent setting them. I think that was not chosen because it leaks the 
internals of the package.

But I'm not sure why they need distinct addresses in the first place. I'm 
guessing its for debugging or just what makes sense? context.TODO and 
context.Background are two different contexts and should be treated as such.

On Friday, November 17, 2017 at 10:43:29 AM UTC-5, Alex Buchanan wrote:
>
> I don't have numbers, but context must be one of the most commonly used 
> imports/types in my code. It shows up many function signatures. We try to 
> use it for all cancelation.
>
> Would it make sense to add an alias "C" to the type "Context"? And maybe 
> "BG" for Background()? 
>
> Also, is there a specific reason Background is a function and not a value?
>
> Cheers,
> Alex
>

-- 
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: invitation to gophers.slack.com

[Matteo G.]

Hi, I don't understood how I can sign up to ghopers.slack.com. Some 
suggestion?

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