[go-nuts] How can I make changes in `printer.go` affect `gofmt` tests?

[mlg]

I'm tinkering with gofmt. I've been able to work with gofmt tests, but I 
don't understand the `printer.go` tests.
The modifications I want to tinker with are in `printer.go`, but the gofmt 
tests I write seem to compile a different unmodified version of printer.go 
than the one I checked out.

The problem must be package related, because my gofmt tests see my changes 
in the gofmt source, but those same tests don't see my changes in the 
printer source.

An alternative solution to my problem would be to understand the printer 
tests.

I've done a little research to resolve this myself:
https://groups.google.com/forum/#!searchin/golang-nuts/gofmt|sort:relevance/golang-nuts/JBvEoyPJlL0/0QVENRS78r0J
https://groups.google.com/forum/#!searchin/golang-nuts/gofmt|sort:relevance/golang-nuts/5RlC11J7XNE/CIMI7yySfkwJ

Florin was unable to get a spec and was later unable to work on the project 
(according to a small chat we had), and gri (author of gofmt) answering 
this for me would be my best bet, but I can't see any info relevant to my 
question in his post.

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] Is it safe to close a channel once more in this way ?

[Tamás Gulácsi]

Use sync.Once - but there's a simple rule that helps:
Let the writer/producer close the channel!

-- 
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: Is it safe to close a channel once more in this way ?

[Dave Cheney]

https://play.golang.org/p/LadBqwgxxr _may_ be a fix, but the similarity to 
the discredited double check lock pattern is worrying.

On Wednesday, 14 December 2016 15:32:57 UTC+11, Dave Cheney wrote:
>
> Nope, it's not safe.
>
> https://play.golang.org/p/pcPdKixphL
>
> Run this program in a loop and it will panic eventually.
>
> On Wednesday, 14 December 2016 15:19:24 UTC+11, P Q wrote:
>>
>> func close_safe(c chan bool) {
>> select {
>> case <-c:
>> default:
>> close(c)
>> }
>> }
>>
>> Closing a channel onece more can be a controversial topic, sometimes it is 
>> useuful.
>> I saw the code to close a closed channel. I thought the code looked nice 
>> at first, but could become errernous.
>>
>> Let's assume that two gorutines will try to close the channel and the 
>> channel has not been closed. At first, groutine 1 enters the default block. 
>> At this time, gorutine schedule changes so that groutine 2 gets the 
>> execution. and the groutine 2 enters the default block, and closes the 
>> channel. schedule changes, gorutine 1 restores its execution and will panic 
>> by closing the closed channel.
>>
>> Could this way happen?
>>
>>

-- 
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: Is it safe to close a channel once more in this way ?

[Dave Cheney]

Nope, it's not safe.

https://play.golang.org/p/pcPdKixphL

Run this program in a loop and it will panic eventually.

On Wednesday, 14 December 2016 15:19:24 UTC+11, P Q wrote:
>
> func close_safe(c chan bool) {
> select {
> case <-c:
> default:
> close(c)
> }
> }
>
> Closing a channel onece more can be a controversial topic, sometimes it is 
> useuful.
> I saw the code to close a closed channel. I thought the code looked nice 
> at first, but could become errernous.
>
> Let's assume that two gorutines will try to close the channel and the 
> channel has not been closed. At first, groutine 1 enters the default block. 
> At this time, gorutine schedule changes so that groutine 2 gets the 
> execution. and the groutine 2 enters the default block, and closes the 
> channel. schedule changes, gorutine 1 restores its execution and will panic 
> by closing the closed channel.
>
> Could this way happen?
>
>

-- 
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] Is it safe to close a channel once more in this way ?

[P Q]

func close_safe(c chan bool) {
select {
case <-c:
default:
close(c)
}
}

Closing a channel onece more can be a controversial topic, sometimes it is 
useuful.
I saw the code to close a closed channel. I thought the code looked nice at 
first, but could become errernous.

Let's assume that two gorutines will try to close the channel and the 
channel has not been closed. At first, groutine 1 enters the default block. 
At this time, gorutine schedule changes so that groutine 2 gets the 
execution. and the groutine 2 enters the default block, and closes the 
channel. schedule changes, gorutine 1 restores its execution and will panic 
by closing the closed channel.

Could this way happen?

-- 
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: Channels and Mutexs

[Dave Cheney]

On Wednesday, 14 December 2016 13:06:54 UTC+11, 
sdi...@watchtower-security.com wrote:
>
>  Why would one want to use channels in place of mutexs? 
>

When you want to use select. 

-- 
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] Channels and Mutexs

[Ian Lance Taylor]

On Tue, Dec 13, 2016 at 6:06 PM,   wrote:
>
> So, I was talking with a friend about channels and mutexs, and the use of
> mutexs instead of channels. While I'm not sure why you'd want to, I was
> given this example and not an answer.
>
> In the example, he declares two channels. Input and Output. Then, he has a
> function running a for select loop in a gorutine. The input object accepts a
> text of body(string) and an ID (int), to which it stores it in a map. Then,
> the output channel accepts a request id (int), and a chan string. When
> something is put on the output channel, he gets the body of text out of the
> map and writes it to the output object's return channel and then closes it.
>
> My question, is this a good practice? Why would one want to use channels in
> place of mutexs? Is this efficient?

I expect that a mutex will be more efficient, and I would probably
write this code with a Mutex or a RWMutex.  But the advantage of this
code is that it is clearly free of concurrency problems and race
conditions.  Especially for more complex cases, that is not a
negligible feature.

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] Channels and Mutexs

[sdickey]

So, I was talking with a friend about channels and mutexs, and the use of 
mutexs instead of channels. While I'm not sure why you'd want to, I was 
given this  example and not an answer.

In the example, he declares two channels. Input and Output. Then, he has a 
function running a for select loop in a gorutine. The input object accepts 
a text of body(string) and an ID (int), to which it stores it in a map. 
Then, the output channel accepts a request id (int), and a chan string. 
When something is put on the output channel, he gets the body of text out 
of the map and writes it to the output object's return channel and then 
closes it. 

My question, is this a good practice? Why would one want to use channels in 
place of mutexs? Is this efficient? 

-- 
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: Code-base Refactoring Tool for Go , Move files from packages to sub packages

[Dave Cheney]

I advice caution, Go is not Java and does not permit circular dependencies. 
The more packages you have, the greater the chance you have of creating a 
circular dependency. 

On Wednesday, 14 December 2016 00:58:00 UTC+11, jis...@hifx.co.in wrote:
>
>
>
> http://stackoverflow.com/questions/41121448/code-base-refactoring-tool-for-go-move-files-from-packages-to-sub-packages
>
> Currently my code-base have just 1 level of packages , due to the increase 
> in number of components it would make much sense if I use sub packages.Is 
> there any code refactoring tools I could use to achieve this.
>
> Package_1/
>   -- File 1
>   -- File 2
>   -- File 3
>   -- File 4Package_2/
>   -- File 5
>   -- File 6
>   -- File 7
>
> Target structure
>
> Package_1
>   /subpackage1
>-- File 1
>-- File 2
>   /subpackage2
>-- File 3
>-- File 4Package_2/
>/subpackage3
>-- File 5
>-- File 6
>/subpackage4
>-- File 4  
>
> I tried *gomvpkg* https://godoc.org/golang.org/x/tools/cmd/gomvpkg but 
> doesnot support moving files from same package to different package.
>
> --
> IMPORTANT: This is an e-mail from HiFX IT Media Services Pvt. Ltd. Its 
> content are confidential to the intended recipient. If you are not the 
> intended recipient, be advised that you have received this e-mail in error 
> and that any use, dissemination, forwarding, printing or copying of this 
> e-mail is strictly prohibited. It may not be disclosed to or used by anyone 
> other than its intended recipient, nor may it be copied in any way. If 
> received in error, please email a reply to the sender, then delete it from 
> your system. 
>
> Although this e-mail has been scanned for viruses, HiFX cannot ultimately 
> accept any responsibility for viruses and it is your responsibility to scan 
> attachments (if any).
>
> ​
> Before you print this email or attachments, please consider the negative 
> environmental impacts associated with printing.

-- 
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: Cache or tmp file used by golang compiler?

[ddxgz19880813]

Hi Uriel,

How did you solve this problem? Because I'm facing the same.

在 2015年8月12日星期三 UTC+2上午10:29:39，Uriel Fanelli写道：
>
>
> Hi all
>
> I am facing a strange behavior in "go build"  process.
>
> What I am doing is , from time to time, to do a git pull from a github 
> repository and recompile the source
> of a program. (the program is "gogs", https://github.com/gogits/gogs , 
> just for mention).
>
> What happens to me is that I compile an executable , and the binary is 
> always the same, regardless the source
> code has changed. 
>
> At the beginning I tried with all favours of "go clean", like "go clean 
> -r" , but the result is the same: after a certain moment,
> dunno why, one machine has continued to produce  an "old" binary, and it 
> was the machine I used to compile the same program in the past.
>
> Now, my question is: is there any kind of cache, tmp file, whatever the 
> compiler uses, which I could try to clean 
> in order to have a very new executable? This issue is making me crazy, 
> seems this machine is producing always the same
> executable.
>
> The version of golang I'm using is 1.4.2  64 bit, CC=gcc48
>
> Uriel
>
>
>
>

-- 
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: net/http best way to get request/response header size

[Nick V]

For what it's worth, MaxHeaderSize only works for POST/PUT requests.

On Tuesday, December 13, 2016 at 11:19:06 AM UTC-8, Tamás Gulácsi wrote:
>
> 2016. december 13., kedd 14:57:47 UTC+1 időpontban kaitoY Kors a 
> következőt írta:
>>
>> Hello,
>>
>> In the current implementation of net/http and net/textproto, other than 
>> iterating all the key/value pairs of Header, type map[string][]string, is 
>> there any other way to get the total size effectively?
>> The concern is if the header contains lots of key/value pairs, it might 
>> be inefficient to get the size by walking through the map.
>>
>> Any advice/comment is appreciated.
>> Thanks in advance
>>
>
> Why do you need the total size? Content-Length is just the body.
> At the time you get the *http.Request in your handler, it's already parsed.
>
> If you want to limit the header's size, use net/http.Server.MaxHeaderSize.
>

-- 
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: Looking for Golang counterpart to 'params' in Python

[Justin Israel]

On Wed, Dec 14, 2016 at 11:39 AM Betsy Lichtenberg 
wrote:

> Interesting. Thanks for the idea, but for security reasons I'm not sure if
> it's something we can do. For some background, the reason I started down
> this road is we cannot include the auth parameter in the request URL.
>

I was actually just looking at the corresponding feature to the "params"
feature you were pointing at in the python requests module. TBH I am not
sure if the requests module does some extra magic to remove "auth" from
that and pass it more securely for you. Only suggesting that the "params"
keyword arg has the similar properties to setting Values on a url.Url and
making a request.


>
> https://developer-api.nest.com/structures?auth=x
>
>
> http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param
>
> "Because of the security weaknesses associated with the URI method,
> including the high likelihood that the URL containing the access token will
> be logged, it SHOULD NOT be used unless it is impossible to transport the
> access token in the Authorization request header field or the HTTP request
> entity-body. Resource servers MAY support this method.
>
> This method is included to document current use; its use is not
> recommended, due to its security deficiencies..."
>
> On Tue, Dec 13, 2016 at 2:16 PM, Justin Israel 
> wrote:
>
> Hi,
>
> While others have been talking about headers, I notice that you are using
> the python requests 3rd party library, and referring to the "params"
> keyword arg which is meant to pass query string values in your GET request.
>
> I would think the equivalent in Go would be to:
>
>
>1. Build the equivalent of the python "params" dictionary using
>url.Values 
>2. Build your *url.Url , with
>that url.Values object
>3. Build an *http.Request 
>with that *url.Url
>4. Run your GET request via http.Client.Do()
>
>
> Justin
>
>
> On Wed, Dec 14, 2016 at 8:33 AM 'Chris Manghane' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> I see, well that makes the compiler error make more sense. You're trying
> to declare a function type within a function. Use a function literal
> instead, for example: `doIT := func(p Params) string { ... }`.
>
> On Tue, Dec 13, 2016 at 11:18 AM, Betsy Lichtenberg 
> wrote:
>
> The expression is inside of the main function.
>
> package main
>
> import (
> "fmt"
> "strings"
> "net/http"
> "io/ioutil"
> )
>
> func main() {
>
> url := "https://developer-api.nest.com/structures;
>
> payload :=
> strings.NewReader("code=a_id=_secret=_type=authorization_code")
>
> req, _ := http.NewRequest("GET", url, payload)
>
> req.Header.Add("content-type", "application/json")
>
> type Params struct {
> auth string
> }
>
> func doIt(p Params) string {
>   return p.auth
> }
>
> doIt(Params{auth: })
>
> res, _ := http.DefaultClient.Do(req)
>
> defer res.Body.Close()
> body, _ := ioutil.ReadAll(res.Body)
>
> fmt.Println(res)
> fmt.Println(string(body))
>
> }
>
> On Tue, Dec 13, 2016 at 11:13 AM, Chris Manghane  wrote:
>
> That error seems to be from writing that expression outside of a function.
> There's no problem with structs supporting string fields:
> https://play.golang.org/p/YeP2qhRdxp.
>
> On Tue, Dec 13, 2016 at 10:45 AM, Betsy Lichtenberg 
> wrote:
>
> Do structs support strings? I tried this:
>
> type Params struct {
>   auth string
> }
>
> func doIt(p Params) string {
>   return p.auth
> }
>
> doIt(Params{auth: })
>
>
> I'm getting these errors:
>
> betsyl-macbookpro:~ betsyl$ go run get1.go
>
> # command-line-arguments
>
> ./get1.go:25: syntax error: unexpected doIt, expecting (
>
> ./get1.go:29: syntax error: unexpected literal .2, expecting comma or }
>
> On Tue, Dec 13, 2016 at 7:11 AM, Val  wrote:
>
> Hello Betsy
> There is no "passing optional arguments by name" in go.
>
> This link [1] has an overview what what can or can't be done for optional
> params :
> - the *Functional options* technique.
> - or you may define a struct as parameter, then call it with only the
> fields you're interested in : [2]
> This implies that "the zero values must be meaningful (i.e. acceptable in
> your context : nil, 0, etc.)"
>
>   things := Things{amount: 13}
>   show(things)
>
> [1] http://stackoverflow.com/questions/2032149/optional-parameters
> [2] https://play.golang.org/p/yiKzomwTKM
>
> On Tuesday, December 13, 2016 at 6:46:23 AM UTC+1, bet...@google.com
> wrote:
>
> Hi,
>
> In Python, I can include params like this:
>
> =
>
> *params = {'auth': ''}*
>
> response = requests.request("GET", url, data=payload, 

Re: [go-nuts] Re: Looking for Golang counterpart to 'params' in Python

[Betsy Lichtenberg]

For what it's worth, a friend of mine advised me to use maps.
https://blog.golang.org/go-maps-in-action


But, alas, I'm not enough of a guru to do anything fancy.

On Tue, Dec 13, 2016 at 2:16 PM, Justin Israel 
wrote:

> Hi,
>
> While others have been talking about headers, I notice that you are using
> the python requests 3rd party library, and referring to the "params"
> keyword arg which is meant to pass query string values in your GET request.
>
> I would think the equivalent in Go would be to:
>
>
>1. Build the equivalent of the python "params" dictionary using
>url.Values 
>2. Build your *url.Url , with
>that url.Values object
>3. Build an *http.Request 
>with that *url.Url
>4. Run your GET request via http.Client.Do()
>
>
> Justin
>
>
> On Wed, Dec 14, 2016 at 8:33 AM 'Chris Manghane' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> I see, well that makes the compiler error make more sense. You're trying
>> to declare a function type within a function. Use a function literal
>> instead, for example: `doIT := func(p Params) string { ... }`.
>>
>> On Tue, Dec 13, 2016 at 11:18 AM, Betsy Lichtenberg 
>> wrote:
>>
>> The expression is inside of the main function.
>>
>> package main
>>
>> import (
>> "fmt"
>> "strings"
>> "net/http"
>> "io/ioutil"
>> )
>>
>> func main() {
>>
>> url := "https://developer-api.nest.com/structures;
>>
>> payload := strings.NewReader("code=a_id=_secret=
>> _type=authorization_code")
>>
>> req, _ := http.NewRequest("GET", url, payload)
>>
>> req.Header.Add("content-type", "application/json")
>>
>> type Params struct {
>> auth string
>> }
>>
>> func doIt(p Params) string {
>>   return p.auth
>> }
>>
>> doIt(Params{auth: })
>>
>> res, _ := http.DefaultClient.Do(req)
>>
>> defer res.Body.Close()
>> body, _ := ioutil.ReadAll(res.Body)
>>
>> fmt.Println(res)
>> fmt.Println(string(body))
>>
>> }
>>
>> On Tue, Dec 13, 2016 at 11:13 AM, Chris Manghane 
>> wrote:
>>
>> That error seems to be from writing that expression outside of a
>> function. There's no problem with structs supporting string fields:
>> https://play.golang.org/p/YeP2qhRdxp.
>>
>> On Tue, Dec 13, 2016 at 10:45 AM, Betsy Lichtenberg 
>> wrote:
>>
>> Do structs support strings? I tried this:
>>
>> type Params struct {
>>   auth string
>> }
>>
>> func doIt(p Params) string {
>>   return p.auth
>> }
>>
>> doIt(Params{auth: })
>>
>>
>> I'm getting these errors:
>>
>> betsyl-macbookpro:~ betsyl$ go run get1.go
>>
>> # command-line-arguments
>>
>> ./get1.go:25: syntax error: unexpected doIt, expecting (
>>
>> ./get1.go:29: syntax error: unexpected literal .2, expecting comma or }
>>
>> On Tue, Dec 13, 2016 at 7:11 AM, Val  wrote:
>>
>> Hello Betsy
>> There is no "passing optional arguments by name" in go.
>>
>> This link [1] has an overview what what can or can't be done for optional
>> params :
>> - the *Functional options* technique.
>> - or you may define a struct as parameter, then call it with only the
>> fields you're interested in : [2]
>> This implies that "the zero values must be meaningful (i.e. acceptable in
>> your context : nil, 0, etc.)"
>>
>>   things := Things{amount: 13}
>>   show(things)
>>
>> [1] http://stackoverflow.com/questions/2032149/optional-parameters
>> [2] https://play.golang.org/p/yiKzomwTKM
>>
>> On Tuesday, December 13, 2016 at 6:46:23 AM UTC+1, bet...@google.com
>> wrote:
>>
>> Hi,
>>
>> In Python, I can include params like this:
>>
>> =
>>
>> *params = {'auth': ''}*
>>
>> response = requests.request("GET", url, data=payload, headers=headers,
>> *params=params*)
>>
>> =
>>
>> Any pointers on how Golang does this?
>>
>> Thanks,
>> Betsy
>>
>>
>> --
>> 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 

Re: [go-nuts] Re: Looking for Golang counterpart to 'params' in Python

[Betsy Lichtenberg]

Interesting. Thanks for the idea, but for security reasons I'm not sure if
it's something we can do. For some background, the reason I started down
this road is we cannot include the auth parameter in the request URL.

https://developer-api.nest.com/structures?auth=x


http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param

"Because of the security weaknesses associated with the URI method,
including the high likelihood that the URL containing the access token will
be logged, it SHOULD NOT be used unless it is impossible to transport the
access token in the Authorization request header field or the HTTP request
entity-body. Resource servers MAY support this method.

This method is included to document current use; its use is not
recommended, due to its security deficiencies..."

On Tue, Dec 13, 2016 at 2:16 PM, Justin Israel 
wrote:

> Hi,
>
> While others have been talking about headers, I notice that you are using
> the python requests 3rd party library, and referring to the "params"
> keyword arg which is meant to pass query string values in your GET request.
>
> I would think the equivalent in Go would be to:
>
>
>1. Build the equivalent of the python "params" dictionary using
>url.Values 
>2. Build your *url.Url , with
>that url.Values object
>3. Build an *http.Request 
>with that *url.Url
>4. Run your GET request via http.Client.Do()
>
>
> Justin
>
>
> On Wed, Dec 14, 2016 at 8:33 AM 'Chris Manghane' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> I see, well that makes the compiler error make more sense. You're trying
>> to declare a function type within a function. Use a function literal
>> instead, for example: `doIT := func(p Params) string { ... }`.
>>
>> On Tue, Dec 13, 2016 at 11:18 AM, Betsy Lichtenberg 
>> wrote:
>>
>> The expression is inside of the main function.
>>
>> package main
>>
>> import (
>> "fmt"
>> "strings"
>> "net/http"
>> "io/ioutil"
>> )
>>
>> func main() {
>>
>> url := "https://developer-api.nest.com/structures;
>>
>> payload := strings.NewReader("code=a_id=_secret=
>> _type=authorization_code")
>>
>> req, _ := http.NewRequest("GET", url, payload)
>>
>> req.Header.Add("content-type", "application/json")
>>
>> type Params struct {
>> auth string
>> }
>>
>> func doIt(p Params) string {
>>   return p.auth
>> }
>>
>> doIt(Params{auth: })
>>
>> res, _ := http.DefaultClient.Do(req)
>>
>> defer res.Body.Close()
>> body, _ := ioutil.ReadAll(res.Body)
>>
>> fmt.Println(res)
>> fmt.Println(string(body))
>>
>> }
>>
>> On Tue, Dec 13, 2016 at 11:13 AM, Chris Manghane 
>> wrote:
>>
>> That error seems to be from writing that expression outside of a
>> function. There's no problem with structs supporting string fields:
>> https://play.golang.org/p/YeP2qhRdxp.
>>
>> On Tue, Dec 13, 2016 at 10:45 AM, Betsy Lichtenberg 
>> wrote:
>>
>> Do structs support strings? I tried this:
>>
>> type Params struct {
>>   auth string
>> }
>>
>> func doIt(p Params) string {
>>   return p.auth
>> }
>>
>> doIt(Params{auth: })
>>
>>
>> I'm getting these errors:
>>
>> betsyl-macbookpro:~ betsyl$ go run get1.go
>>
>> # command-line-arguments
>>
>> ./get1.go:25: syntax error: unexpected doIt, expecting (
>>
>> ./get1.go:29: syntax error: unexpected literal .2, expecting comma or }
>>
>> On Tue, Dec 13, 2016 at 7:11 AM, Val  wrote:
>>
>> Hello Betsy
>> There is no "passing optional arguments by name" in go.
>>
>> This link [1] has an overview what what can or can't be done for optional
>> params :
>> - the *Functional options* technique.
>> - or you may define a struct as parameter, then call it with only the
>> fields you're interested in : [2]
>> This implies that "the zero values must be meaningful (i.e. acceptable in
>> your context : nil, 0, etc.)"
>>
>>   things := Things{amount: 13}
>>   show(things)
>>
>> [1] http://stackoverflow.com/questions/2032149/optional-parameters
>> [2] https://play.golang.org/p/yiKzomwTKM
>>
>> On Tuesday, December 13, 2016 at 6:46:23 AM UTC+1, bet...@google.com
>> wrote:
>>
>> Hi,
>>
>> In Python, I can include params like this:
>>
>> =
>>
>> *params = {'auth': ''}*
>>
>> response = requests.request("GET", url, data=payload, headers=headers,
>> *params=params*)
>>
>> =
>>
>> Any pointers on how Golang does this?
>>
>> Thanks,
>> Betsy
>>
>>
>> --
>> 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, 

Re: [go-nuts] Re: Looking for Golang counterpart to 'params' in Python

[Justin Israel]

Hi,

While others have been talking about headers, I notice that you are using
the python requests 3rd party library, and referring to the "params"
keyword arg which is meant to pass query string values in your GET request.

I would think the equivalent in Go would be to:


   1. Build the equivalent of the python "params" dictionary using
   url.Values 
   2. Build your *url.Url , with that
   url.Values object
   3. Build an *http.Request 
   with that *url.Url
   4. Run your GET request via http.Client.Do()
   

Justin


On Wed, Dec 14, 2016 at 8:33 AM 'Chris Manghane' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I see, well that makes the compiler error make more sense. You're trying
> to declare a function type within a function. Use a function literal
> instead, for example: `doIT := func(p Params) string { ... }`.
>
> On Tue, Dec 13, 2016 at 11:18 AM, Betsy Lichtenberg 
> wrote:
>
> The expression is inside of the main function.
>
> package main
>
> import (
> "fmt"
> "strings"
> "net/http"
> "io/ioutil"
> )
>
> func main() {
>
> url := "https://developer-api.nest.com/structures;
>
> payload :=
> strings.NewReader("code=a_id=_secret=_type=authorization_code")
>
> req, _ := http.NewRequest("GET", url, payload)
>
> req.Header.Add("content-type", "application/json")
>
> type Params struct {
> auth string
> }
>
> func doIt(p Params) string {
>   return p.auth
> }
>
> doIt(Params{auth: })
>
> res, _ := http.DefaultClient.Do(req)
>
> defer res.Body.Close()
> body, _ := ioutil.ReadAll(res.Body)
>
> fmt.Println(res)
> fmt.Println(string(body))
>
> }
>
> On Tue, Dec 13, 2016 at 11:13 AM, Chris Manghane  wrote:
>
> That error seems to be from writing that expression outside of a function.
> There's no problem with structs supporting string fields:
> https://play.golang.org/p/YeP2qhRdxp.
>
> On Tue, Dec 13, 2016 at 10:45 AM, Betsy Lichtenberg 
> wrote:
>
> Do structs support strings? I tried this:
>
> type Params struct {
>   auth string
> }
>
> func doIt(p Params) string {
>   return p.auth
> }
>
> doIt(Params{auth: })
>
>
> I'm getting these errors:
>
> betsyl-macbookpro:~ betsyl$ go run get1.go
>
> # command-line-arguments
>
> ./get1.go:25: syntax error: unexpected doIt, expecting (
>
> ./get1.go:29: syntax error: unexpected literal .2, expecting comma or }
>
> On Tue, Dec 13, 2016 at 7:11 AM, Val  wrote:
>
> Hello Betsy
> There is no "passing optional arguments by name" in go.
>
> This link [1] has an overview what what can or can't be done for optional
> params :
> - the *Functional options* technique.
> - or you may define a struct as parameter, then call it with only the
> fields you're interested in : [2]
> This implies that "the zero values must be meaningful (i.e. acceptable in
> your context : nil, 0, etc.)"
>
>   things := Things{amount: 13}
>   show(things)
>
> [1] http://stackoverflow.com/questions/2032149/optional-parameters
> [2] https://play.golang.org/p/yiKzomwTKM
>
> On Tuesday, December 13, 2016 at 6:46:23 AM UTC+1, bet...@google.com
> wrote:
>
> Hi,
>
> In Python, I can include params like this:
>
> =
>
> *params = {'auth': ''}*
>
> response = requests.request("GET", url, data=payload, headers=headers,
> *params=params*)
>
> =
>
> Any pointers on how Golang does this?
>
> Thanks,
> Betsy
>
>
> --
> 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.

[go-nuts] Re: Evaluation order

[Rafał Jęczalik]

Dave, the example you have on your blog post is the same as the one in spec 
I linked and is different than mine - the f is called before a is 
evaluated, if we assumed left-to-right evaluation order. In the spec's 
example a is evaluated before f is called.

I tested my example on both gccgo and go and it gives the same result - "3 
2". Thus the question.

Nevertheless the rationale given by Ian makes sense to me, so for the time 
being I will assume it's not safe to write code that depends on this 
behavior.

Thank you for all your comments!

--
Rafal

On Tuesday, December 13, 2016 at 9:50:43 PM UTC+1, Dave Cheney wrote:
>
> The order of evaluation is not specified. We found a few years ago that 
> gccgo and gc differed in this respect and _both_ implantations are correct. 
>
> https://dave.cheney.net/2013/11/15/evaluation-order-oddity
>

-- 
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] Evaluation order

[Dave Cheney]

The order of evaluation is not specified. We found a few years ago that gccgo 
and gc differed in this respect and _both_ implantations are correct. 

https://dave.cheney.net/2013/11/15/evaluation-order-oddity

-- 
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: How to speed up execution time for a set of regular expressions

[Michael Jones]

I like regular expressions, but I always think of them as a last resort,
sort of like finding your way through a labyrinth by feel. When you know
more about the structure of the mystery -- "keep your left hand on the
wall" or "spaces separate tokens"-- then other tools and approaches can
help tremendously in terms of speed, and size.

If there are keywords and there is a simple way to separate keywords
without deep understanding what has come before or what comes after, then a
two-stage lex/parse scheme may be suggested.

If the quest is mostly about keywords rather than the relative structure of
keywords, as in "find these hundred thousand words in this hundred billion
word corpus, then sophisticated linear approaches are suggested.

I have often been able to get huge speedups by doing just what Andy
suggested as I am typing here...by considering the match process as
iterative or as a series of mappings and matchings. Often the "or else" and
"or backup" can be avoided by an earlier pass.

Good luck!

On Tue, Dec 13, 2016 at 11:34 AM, David Sofo  wrote:

> Thanks Tamas. I am not aware of Ragel.
> Regard
> David
>
>
> Le mardi 13 décembre 2016 20:24:18 UTC+1, Tamás Gulácsi a écrit :
>>
>> 2016. december 13., kedd 16:53:45 UTC+1 időpontban David Sofo a
>> következőt írta:
>>>
>>>  Hi,
>>>
>>> For a set of rules expressed in regular expression (around 1000 rules
>>> expected) to find some keywords in a text file (~50Ko each file), how to
>>> speed up the execution time. Currently I compile the regex rule at
>>> initialization time with init function at put them in a map at package
>>> level then run the regex rules with a loop. The regex have this form:
>>>
>>> \b(?:( (A1|A2|A3) | (B1|B2|B3) ) )\b
>>>
>>> spaces are put for readability. A and B are classes of keywords.
>>>
>>> How to speed up the execution: at regular expression level or others
>>> levels (such execution priority). I am using Ubuntu 14.04. Any suggestion
>>> is welcome.  Thank you.
>>>
>>> Here a code
>>>
>>> Regards
>>> David
>>>
>>>
>> Are these really just words? Then split the string first, then match
>> these tokens.
>> Or try to create one huge regexp - maybe that's faster.
>> Or create one huge regexp, roll it through Ragel, and use the generated
>> Go code.
>>
> --
> 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.
>



-- 
Michael T. Jones
michael.jo...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How to speed up execution time for a set of regular expressions

[Andy Balholm]

Right. Aho-Corasick can’t be used directly in that case.

But it might still be a major performance win to use Aho-Corasick for the first 
pass, and then confirm with regexes. In other words, if the Aho-Corasick stage 
finds “associate,” then check whether /associate.*with/ matches.

Andy

-- 
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 speed up execution time for a set of regular expressions

[David Sofo]

Thanks Tamas. I am not aware of Ragel.
Regard
David

Le mardi 13 décembre 2016 20:24:18 UTC+1, Tamás Gulácsi a écrit :
>
> 2016. december 13., kedd 16:53:45 UTC+1 időpontban David Sofo a következőt 
> írta:
>>
>>  Hi,
>>
>> For a set of rules expressed in regular expression (around 1000 rules 
>> expected) to find some keywords in a text file (~50Ko each file), how to 
>> speed up the execution time. Currently I compile the regex rule at 
>> initialization time with init function at put them in a map at package 
>> level then run the regex rules with a loop. The regex have this form:
>>
>> \b(?:( (A1|A2|A3) | (B1|B2|B3) ) )\b
>>
>> spaces are put for readability. A and B are classes of keywords.
>>
>> How to speed up the execution: at regular expression level or others 
>> levels (such execution priority). I am using Ubuntu 14.04. Any suggestion 
>> is welcome.  Thank you.
>>
>> Here a code
>>
>> Regards
>> David
>>
>>
> Are these really just words? Then split the string first, then match these 
> tokens.
> Or try to create one huge regexp - maybe that's faster.
> Or create one huge regexp, roll it through Ragel, and use the generated Go 
> code. 
>

-- 
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: Looking for Golang counterpart to 'params' in Python

['Chris Manghane' via golang-nuts]

I see, well that makes the compiler error make more sense. You're trying to
declare a function type within a function. Use a function literal instead,
for example: `doIT := func(p Params) string { ... }`.

On Tue, Dec 13, 2016 at 11:18 AM, Betsy Lichtenberg 
wrote:

> The expression is inside of the main function.
>
> package main
>
> import (
> "fmt"
> "strings"
> "net/http"
> "io/ioutil"
> )
>
> func main() {
>
> url := "https://developer-api.nest.com/structures;
>
> payload := strings.NewReader("code=a_id=_secret=
> _type=authorization_code")
>
> req, _ := http.NewRequest("GET", url, payload)
>
> req.Header.Add("content-type", "application/json")
>
> type Params struct {
> auth string
> }
>
> func doIt(p Params) string {
>   return p.auth
> }
>
> doIt(Params{auth: })
>
> res, _ := http.DefaultClient.Do(req)
>
> defer res.Body.Close()
> body, _ := ioutil.ReadAll(res.Body)
>
> fmt.Println(res)
> fmt.Println(string(body))
>
> }
>
> On Tue, Dec 13, 2016 at 11:13 AM, Chris Manghane  wrote:
>
>> That error seems to be from writing that expression outside of a
>> function. There's no problem with structs supporting string fields:
>> https://play.golang.org/p/YeP2qhRdxp.
>>
>> On Tue, Dec 13, 2016 at 10:45 AM, Betsy Lichtenberg 
>> wrote:
>>
>>> Do structs support strings? I tried this:
>>>
>>> type Params struct {
>>>   auth string
>>> }
>>>
>>> func doIt(p Params) string {
>>>   return p.auth
>>> }
>>>
>>> doIt(Params{auth: })
>>>
>>>
>>> I'm getting these errors:
>>>
>>> betsyl-macbookpro:~ betsyl$ go run get1.go
>>>
>>> # command-line-arguments
>>>
>>> ./get1.go:25: syntax error: unexpected doIt, expecting (
>>>
>>> ./get1.go:29: syntax error: unexpected literal .2, expecting comma or }
>>>
>>> On Tue, Dec 13, 2016 at 7:11 AM, Val  wrote:
>>>
 Hello Betsy
 There is no "passing optional arguments by name" in go.

 This link [1] has an overview what what can or can't be done for
 optional params :
 - the *Functional options* technique.
 - or you may define a struct as parameter, then call it with only the
 fields you're interested in : [2]
 This implies that "the zero values must be meaningful (i.e. acceptable
 in your context : nil, 0, etc.)"

   things := Things{amount: 13}
   show(things)

 [1] http://stackoverflow.com/questions/2032149/optional-parameters
 [2] https://play.golang.org/p/yiKzomwTKM

 On Tuesday, December 13, 2016 at 6:46:23 AM UTC+1, bet...@google.com
 wrote:
>
> Hi,
>
> In Python, I can include params like this:
>
> =
>
> *params = {'auth': ''}*
>
> response = requests.request("GET", url, data=payload, headers=headers,
> *params=params*)
>
> =
>
> Any pointers on how Golang does this?
>
> Thanks,
> Betsy
>

>>> --
>>> 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: How to speed up execution time for a set of regular expressions

[Tamás Gulácsi]

2016. december 13., kedd 16:53:45 UTC+1 időpontban David Sofo a következőt 
írta:
>
>  Hi,
>
> For a set of rules expressed in regular expression (around 1000 rules 
> expected) to find some keywords in a text file (~50Ko each file), how to 
> speed up the execution time. Currently I compile the regex rule at 
> initialization time with init function at put them in a map at package 
> level then run the regex rules with a loop. The regex have this form:
>
> \b(?:( (A1|A2|A3) | (B1|B2|B3) ) )\b
>
> spaces are put for readability. A and B are classes of keywords.
>
> How to speed up the execution: at regular expression level or others 
> levels (such execution priority). I am using Ubuntu 14.04. Any suggestion 
> is welcome.  Thank you.
>
> Here a code
>
> Regards
> David
>
>
Are these really just words? Then split the string first, then match these 
tokens.
Or try to create one huge regexp - maybe that's faster.
Or create one huge regexp, roll it through Ragel, and use the generated Go 
code. 

-- 
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: Looking for Golang counterpart to 'params' in Python

[Betsy Lichtenberg]

The expression is inside of the main function.

package main

import (
"fmt"
"strings"
"net/http"
"io/ioutil"
)

func main() {

url := "https://developer-api.nest.com/structures;

payload :=
strings.NewReader("code=a_id=_secret=_type=authorization_code")

req, _ := http.NewRequest("GET", url, payload)

req.Header.Add("content-type", "application/json")

type Params struct {
auth string
}

func doIt(p Params) string {
  return p.auth
}

doIt(Params{auth: })

res, _ := http.DefaultClient.Do(req)

defer res.Body.Close()
body, _ := ioutil.ReadAll(res.Body)

fmt.Println(res)
fmt.Println(string(body))

}

On Tue, Dec 13, 2016 at 11:13 AM, Chris Manghane  wrote:

> That error seems to be from writing that expression outside of a function.
> There's no problem with structs supporting string fields:
> https://play.golang.org/p/YeP2qhRdxp.
>
> On Tue, Dec 13, 2016 at 10:45 AM, Betsy Lichtenberg 
> wrote:
>
>> Do structs support strings? I tried this:
>>
>> type Params struct {
>>   auth string
>> }
>>
>> func doIt(p Params) string {
>>   return p.auth
>> }
>>
>> doIt(Params{auth: })
>>
>>
>> I'm getting these errors:
>>
>> betsyl-macbookpro:~ betsyl$ go run get1.go
>>
>> # command-line-arguments
>>
>> ./get1.go:25: syntax error: unexpected doIt, expecting (
>>
>> ./get1.go:29: syntax error: unexpected literal .2, expecting comma or }
>>
>> On Tue, Dec 13, 2016 at 7:11 AM, Val  wrote:
>>
>>> Hello Betsy
>>> There is no "passing optional arguments by name" in go.
>>>
>>> This link [1] has an overview what what can or can't be done for
>>> optional params :
>>> - the *Functional options* technique.
>>> - or you may define a struct as parameter, then call it with only the
>>> fields you're interested in : [2]
>>> This implies that "the zero values must be meaningful (i.e. acceptable
>>> in your context : nil, 0, etc.)"
>>>
>>>   things := Things{amount: 13}
>>>   show(things)
>>>
>>> [1] http://stackoverflow.com/questions/2032149/optional-parameters
>>> [2] https://play.golang.org/p/yiKzomwTKM
>>>
>>> On Tuesday, December 13, 2016 at 6:46:23 AM UTC+1, bet...@google.com
>>> wrote:

 Hi,

 In Python, I can include params like this:

 =

 *params = {'auth': ''}*

 response = requests.request("GET", url, data=payload, headers=headers,
 *params=params*)

 =

 Any pointers on how Golang does this?

 Thanks,
 Betsy

>>>
>> --
>> 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] import a "main" package

[Dave Cheney]

There were some difficulties in writing external tests for a main package, 
ie package main_test, but they were resolved a long time ago.

On Wednesday, 14 December 2016 04:18:22 UTC+11, Jan Mercl wrote:
>
> On Tue, Dec 13, 2016 at 6:13 PM adonovan via golang-nuts <
> golan...@googlegroups.com > wrote:
>
> > Packages named main are importable, just like any other. Occasionally 
> this is useful when you want to write tests for members of that package. Of 
> course, the main function is not exported.
>
> I recall running into this limitation years ago. Was it always possible? 
> Or do I have a false remembrance?
>
> -- 
>
> -j
>

-- 
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: Looking for Golang counterpart to 'params' in Python

['Chris Manghane' via golang-nuts]

That error seems to be from writing that expression outside of a function.
There's no problem with structs supporting string fields:
https://play.golang.org/p/YeP2qhRdxp.

On Tue, Dec 13, 2016 at 10:45 AM, Betsy Lichtenberg 
wrote:

> Do structs support strings? I tried this:
>
> type Params struct {
>   auth string
> }
>
> func doIt(p Params) string {
>   return p.auth
> }
>
> doIt(Params{auth: })
>
>
> I'm getting these errors:
>
> betsyl-macbookpro:~ betsyl$ go run get1.go
>
> # command-line-arguments
>
> ./get1.go:25: syntax error: unexpected doIt, expecting (
>
> ./get1.go:29: syntax error: unexpected literal .2, expecting comma or }
>
> On Tue, Dec 13, 2016 at 7:11 AM, Val  wrote:
>
>> Hello Betsy
>> There is no "passing optional arguments by name" in go.
>>
>> This link [1] has an overview what what can or can't be done for optional
>> params :
>> - the *Functional options* technique.
>> - or you may define a struct as parameter, then call it with only the
>> fields you're interested in : [2]
>> This implies that "the zero values must be meaningful (i.e. acceptable in
>> your context : nil, 0, etc.)"
>>
>>   things := Things{amount: 13}
>>   show(things)
>>
>> [1] http://stackoverflow.com/questions/2032149/optional-parameters
>> [2] https://play.golang.org/p/yiKzomwTKM
>>
>> On Tuesday, December 13, 2016 at 6:46:23 AM UTC+1, bet...@google.com
>> wrote:
>>>
>>> Hi,
>>>
>>> In Python, I can include params like this:
>>>
>>> =
>>>
>>> *params = {'auth': ''}*
>>>
>>> response = requests.request("GET", url, data=payload, headers=headers,
>>> *params=params*)
>>>
>>> =
>>>
>>> Any pointers on how Golang does this?
>>>
>>> Thanks,
>>> Betsy
>>>
>>
> --
> 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: Looking for Golang counterpart to 'params' in Python

[Betsy Lichtenberg]

Do structs support strings? I tried this:

type Params struct {
  auth string
}

func doIt(p Params) string {
  return p.auth
}

doIt(Params{auth: })


I'm getting these errors:

betsyl-macbookpro:~ betsyl$ go run get1.go

# command-line-arguments

./get1.go:25: syntax error: unexpected doIt, expecting (

./get1.go:29: syntax error: unexpected literal .2, expecting comma or }

On Tue, Dec 13, 2016 at 7:11 AM, Val  wrote:

> Hello Betsy
> There is no "passing optional arguments by name" in go.
>
> This link [1] has an overview what what can or can't be done for optional
> params :
> - the *Functional options* technique.
> - or you may define a struct as parameter, then call it with only the
> fields you're interested in : [2]
> This implies that "the zero values must be meaningful (i.e. acceptable in
> your context : nil, 0, etc.)"
>
>   things := Things{amount: 13}
>   show(things)
>
> [1] http://stackoverflow.com/questions/2032149/optional-parameters
> [2] https://play.golang.org/p/yiKzomwTKM
>
> On Tuesday, December 13, 2016 at 6:46:23 AM UTC+1, bet...@google.com
> wrote:
>>
>> Hi,
>>
>> In Python, I can include params like this:
>>
>> =
>>
>> *params = {'auth': ''}*
>>
>> response = requests.request("GET", url, data=payload, headers=headers,
>> *params=params*)
>>
>> =
>>
>> Any pointers on how Golang does this?
>>
>> Thanks,
>> Betsy
>>
>

-- 
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] Why does the close built-in panic on previously closed channels?

[go-question]

I see, from reading the Golang spec on the close builtin it wasn't clear to 
me that it was communicating with the receivers.

Thanks for clarifying!



On Tuesday, December 13, 2016 at 10:19:46 AM UTC-8, Ian Lance Taylor wrote:
>
> On Tue, Dec 13, 2016 at 10:03 AM, go-question 
>  wrote: 
> > 
> > Whats the reason behind panicking when calling close on a closed 
> channel? 
> > 
> > Receiving on a closed channel returns the zero value. 
> > Wouldn't it be safer to do a no-op and rely on the multivar return to 
> inform 
> > the caller when it is successful? 
> > 
> > Though, maybe the latter point could be confusing with regard to what 
> was 
> > successful, the channel being closed or the operation. 
>
> Closing a channel is an operation taken by the sender to tell the 
> receiver that there is no more data coming on the channel.  Clearly 
> sending a value on a channel that has been closed is an error.  By 
> analogy, closing a channel that has been closed--trying to send an 
> additional piece of information on that channel, namely that there is 
> no more data coming--is an error. 
>
> 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] Why does the close built-in panic on previously closed channels?

[Ian Lance Taylor]

On Tue, Dec 13, 2016 at 10:03 AM, go-question
 wrote:
>
> Whats the reason behind panicking when calling close on a closed channel?
>
> Receiving on a closed channel returns the zero value.
> Wouldn't it be safer to do a no-op and rely on the multivar return to inform
> the caller when it is successful?
>
> Though, maybe the latter point could be confusing with regard to what was
> successful, the channel being closed or the operation.

Closing a channel is an operation taken by the sender to tell the
receiver that there is no more data coming on the channel.  Clearly
sending a value on a channel that has been closed is an error.  By
analogy, closing a channel that has been closed--trying to send an
additional piece of information on that channel, namely that there is
no more data coming--is an error.

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] Why does the close built-in panic on previously closed channels?

[go-question]

Whats the reason behind panicking when calling close on a closed channel? 

Receiving on a closed channel returns the zero value.
Wouldn't it be safer to do a no-op and rely on the multivar return to 
inform the caller when it is successful?

Though, maybe the latter point could be confusing with regard to what was 
successful, the channel being closed or the operation.



-- 
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] Function scoped method receivers

[go-question]

Thanks rog for the suggestions. I can see the case for mocking as well.


On Tuesday, December 13, 2016 at 5:11:26 AM UTC-8, rog wrote:
>
> On 13 December 2016 at 01:08, go-question  > wrote: 
> > 
> > I noticed that its possible to define/scope types/interfaces in 
> functions. 
> > 
> > Now I'm not arguing that this is good practice, but for the sake of 
> > curiosity. 
> > How can I then add a method w/ a receiver to type foo so that it 
> satisfies 
> > interface ifoo? (in function scope) 
> > 
> > 
> > func main() { 
> > 
> > type foo struct{ 
> > a string 
> > } 
> > 
> > type ifoo interface { 
> > Bar() 
> > } 
> > 
> > // possible? 
> > foo{"baz"}.Bar() 
> > 
> > } 
>
> Technically you can do it (you can make a program that will compile, 
> demonstrating that your type does satisfy the interface) 
> but it's not very useful because it'll crash when you call the method :-) 
>
> package main 
>
> func main() { 
> type ifoo interface { 
> Bar() 
> } 
> type foo struct { 
> ifoo 
> a string 
> } 
> // Yup, it's possible, but it's probably not what you want. 
> foo{a: "baz"}.Bar() 
> } 
>
>
> This is still a useful technique in some circumstances though (for example 
> if there's a large interface that I want to mock only a small portion of, 
> I can embed the interface and define only those methods I expect to be 
> called). 
>
> Another useful technique when you want function-scoped methods is this: 
>
> package main 
>
> import "fmt" 
>
> type ifoo interface { 
> Bar() 
> } 
>
> type ifooFuncs struct { 
> bar func() 
> // ... and another function-typed field for each method. 
> } 
>
> func (f ifooFuncs) Bar() { 
> f.bar() 
> } 
>
> func main() { 
> x := ifooFuncs{ 
> bar: func() { 
> fmt.Println("bar") 
> }, 
> } 
> x.Bar() 
> } 
>

-- 
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] Responsive boxes in go-gtk

[James Ralphs]

I'm writing a desktop application using the Go bindings for GTK at 
https://mattn.github.io/go-gtk/.

I'm showing a set of widgets in a listing "view". I'd like to make it 
responsive - kind of like using the "float" property in CSS.

So far I've looked at VBox, HBox, Table, and the Fixed Layout and Layout 
Container, but none of these really solve my problem - they all scale in 
one direction.

I’m interested in suggestions either within go-gtk, C GTK that would be 
possible to bind, a Go library that would do this for me, or if none of 
those exist, then ideas/best practices for rolling my own.

The result would be a container that "moves" widgets around depending on 
the screen dimensions. I left some ascii-art below of how I'd like it to 
look.

Thanks in advance!

Larger/wider window:


+---+
| app   |
|   |
| +-+  +-+  |
| | |  | |  |
| | w1  |  | w2  |  |
| | |  | |  |
| +-+  +-+  |
|   |
|   |
| +-+   |
| | |   |
| | w3  |   |
| | |   |
| +-+   |
|   |
+---+
Smaller/narrower window:


 ++
| app|
||
| +-+|
| | ||
| | w1  ||
| | ||
| +-+|
||
| +-+|
| | ||
| | w2  ||
| | ||
| +-+|
||
| +-+|
| | ||
| | w3  ||
| | ||
| +-+|
||
++


-- 
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] pprof cum units

[vadim]

According to some older pprof tutorials, the units reported by "top" or 
"web" are the numbers of calls. Newer tutorials as well as my own 
experiments show seconds instead. For example, compare:

(pprof) top10
Total: 2525 samples
 298 11.8% 11.8% 345 13.7% runtime.mapaccess1_fast64
 268 10.6% 22.4% 2124 84.1% main.FindLoops
 251 9.9% 32.4% 451 17.9% scanblock
 178 7.0% 39.4% 351 13.9% hash_insert
 131 5.2% 44.6% 158 6.3% sweepspan
 119 4.7% 49.3% 350 13.9% main.DFS
 96 3.8% 53.1% 98 3.9% flushptrbuf
 95 3.8% 56.9% 95 3.8% runtime.aeshash64
 95 3.8% 60.6% 101 4.0% runtime.settype_flush
 88 3.5% 64.1% 988 39.1% runtime.mallocgc


(taken from https://blog.golang.org/profiling-go-programs) with what I get:

(pprof) top10
1780ms of 3640ms total (48.90%)
Dropped 74 nodes (cum <= 18.20ms)
Showing top 10 nodes out of 197 (cum >= 80ms)
  flat  flat%   sum%cum   cum%
 420ms 11.54% 11.54%  420ms 11.54%  runtime.memmove
 380ms 10.44% 21.98%  790ms 21.70%  runtime.mallocgc
 240ms  6.59% 28.57%  240ms  6.59%  runtime.memclr
 130ms  3.57% 32.14%  720ms 19.78%  compress/flate.(*decompressor).
huffSym
 130ms  3.57% 35.71%  160ms  4.40%  syscall.Syscall
 120ms  3.30% 39.01%  120ms  3.30%  runtime.procyield
 100ms  2.75% 41.76%  100ms  2.75%  crypto/aes.gcmAesDec
  90ms  2.47% 44.23%   90ms  2.47%  runtime.futex
  90ms  2.47% 46.70%   90ms  2.47%  runtime.heapBitsSetType
  80ms  2.20% 48.90%   80ms  2.20%  crypto/sha1.blockAVX2

1. Does the profiling unit depend on OS?
2. Was the profiling unit changed in the past from plain number of calls to 
time (seconds)?
3. Is it possible to force the unit to be the number of calls?

-- 
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] import a "main" package

[Jan Mercl]

On Tue, Dec 13, 2016 at 6:13 PM adonovan via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Packages named main are importable, just like any other. Occasionally
this is useful when you want to write tests for members of that package. Of
course, the main function is not exported.

I recall running into this limitation years ago. Was it always possible? Or
do I have a false remembrance?

-- 

-j

-- 
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] import a "main" package

[adonovan via golang-nuts]

On Tuesday, 13 December 2016 11:34:24 UTC-5, Jan Mercl wrote:
>
> On Tue, Dec 13, 2016 at 5:19 PM Manlio Perillo  > wrote:
>
> > However I think that there is no reason why a "main" package should not 
> be importable, to the point that
> > I think that the fact that a "main" package is not importable is an 
> "exception" implemented in the Go tool.
>
> The package dependency graph must be (1) an acyclic graph, ie. a tree with 
> (2) main package at its root, for obvious reasons. Importing main violates 
> both of the properties.
>

Packages named main are importable, just like any other.  Occasionally this 
is useful when you want to write tests for members of that package.  Of 
course, the main function is not exported.


-- 
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] How to speed up execution time for a set of regular expressions

[David Sofo]

Thank you Andy for your reply, I can have optional classes like (B1|B2|B3)? 
and some keywords are multiword expression it can have some  words within 
its parts. Exemple: *associate … with, **protect … from. Can *Aho-Corasick 
string matching used for this task. If I understood Aho-Corasick string 
matching is for only fixed keywords.

Le mardi 13 décembre 2016 17:31:58 UTC+1, Andy Balholm a écrit :
>
> If it’s actually just a list of keywords (no wildcards, character ranges, 
> etc.), I would recommend using Aho-Corasick string matching rather than 
> regular expressions.
>
> Andy
>
> On Dec 13, 2016, at 7:53 AM, David Sofo  
> wrote:
>
>  Hi,
>
> For a set of rules expressed in regular expression (around 1000 rules 
> expected) to find some keywords in a text file (~50Ko each file), how to 
> speed up the execution time. Currently I compile the regex rule at 
> initialization time with init function at put them in a map at package 
> level then run the regex rules with a loop. The regex have this form:
>
> \b(?:( (A1|A2|A3) | (B1|B2|B3) ) )\b
>
> spaces are put for readability. A and B are classes of keywords.
>
> How to speed up the execution: at regular expression level or others 
> levels (such execution priority). I am using Ubuntu 14.04. Any suggestion 
> is welcome.  Thank you.
>
> Here a code
>
> Regards
> David
>
>
> -- 
> 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...@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] import a "main" package

[Jan Mercl]

On Tue, Dec 13, 2016 at 5:19 PM Manlio Perillo 
wrote:

> However I think that there is no reason why a "main" package should not
be importable, to the point that
> I think that the fact that a "main" package is not importable is an
"exception" implemented in the Go tool.

The package dependency graph must be (1) an acyclic graph, ie. a tree with
(2) main package at its root, for obvious reasons. Importing main violates
both of the properties.
-- 

-j

-- 
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] How to speed up execution time for a set of regular expressions

[Andy Balholm]

If it’s actually just a list of keywords (no wildcards, character ranges, 
etc.), I would recommend using Aho-Corasick string matching rather than regular 
expressions.

Andy

> On Dec 13, 2016, at 7:53 AM, David Sofo  wrote:
> 
>  Hi,
> 
> For a set of rules expressed in regular expression (around 1000 rules 
> expected) to find some keywords in a text file (~50Ko each file), how to 
> speed up the execution time. Currently I compile the regex rule at 
> initialization time with init function at put them in a map at package level 
> then run the regex rules with a loop. The regex have this form:
> 
> \b(?:( (A1|A2|A3) | (B1|B2|B3) ) )\b
> 
> spaces are put for readability. A and B are classes of keywords.
> 
> How to speed up the execution: at regular expression level or others levels 
> (such execution priority). I am using Ubuntu 14.04. Any suggestion is 
> welcome.  Thank you.
> 
> Here a code
> 
> Regards
> David
> 
> 
> -- 
> 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] import a "main" package

[Manlio Perillo]

This is something that I asked in the past, but now it is a feature that I 
probably need for a project.

I have a main package with some data fixtures, stored in the package assets 
directory.
I want to implement a Go tool that, given a package importpath and a Data 
Source Name
(not necessarily an SQL database), loads the data fixtures in the database.

Each fixture file is named after the name of a Go struct, so the tool will 
generate, build and run a Go
source where the package is imported, the data fixture is decoded into a Go 
variable, and then
saved in the database.

This is easy, but the problem is that a main package can not be imported.
Of course I can move the related code to a normal package; and this may 
also improve the code organization.

However I think that there is no reason why a "main" package should not be 
importable, to the point that
I think that the fact that a "main" package is not importable is an 
"exception" implemented in the Go tool.

Is this true?


Thanks  Manlio

-- 
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] How to speed up execution time for a set of regular expressions

[David Sofo]

 Hi,

For a set of rules expressed in regular expression (around 1000 rules 
expected) to find some keywords in a text file (~50Ko each file), how to 
speed up the execution time. Currently I compile the regex rule at 
initialization time with init function at put them in a map at package 
level then run the regex rules with a loop. The regex have this form:

\b(?:( (A1|A2|A3) | (B1|B2|B3) ) )\b

spaces are put for readability. A and B are classes of keywords.

How to speed up the execution: at regular expression level or others levels 
(such execution priority). I am using Ubuntu 14.04. Any suggestion is 
welcome.  Thank you.

Here a code

Regards
David

-- 
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: Code-base Refactoring Tool for Go , Move files from packages to sub packages

[adonovan via golang-nuts]

On Tuesday, 13 December 2016 08:58:00 UTC-5, jis...@hifx.co.in wrote:
>
>
>
> http://stackoverflow.com/questions/41121448/code-base-refactoring-tool-for-go-move-files-from-packages-to-sub-packages
>
> Currently my code-base have just 1 level of packages , due to the increase 
> in number of components it would make much sense if I use sub packages.Is 
> there any code refactoring tools I could use to achieve this?  I tried 
> *gomvpkg* https://godoc.org/golang.org/x/tools/cmd/gomvpkg but doesnot 
> support moving files from same package to different package.
>

We do not currently have a production-quality tool that can split a package 
into two or more parts, although Michael Matloob and I produced an 
experimental prototype of a tool (https://go-review.googlesource.com/3269) 
to analyze and refactor large packages such as "runtime" with complex 
internal dependencies.  It may be more complex than you need, but it might 
save you time.


-- 
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: Looking for Golang counterpart to 'params' in Python

[Val]

Hello Betsy
There is no "passing optional arguments by name" in go.

This link [1] has an overview what what can or can't be done for optional 
params :
- the *Functional options* technique.
- or you may define a struct as parameter, then call it with only the 
fields you're interested in : [2]
This implies that "the zero values must be meaningful (i.e. acceptable in 
your context : nil, 0, etc.)"

  things := Things{amount: 13}
  show(things)

[1] http://stackoverflow.com/questions/2032149/optional-parameters
[2] https://play.golang.org/p/yiKzomwTKM

On Tuesday, December 13, 2016 at 6:46:23 AM UTC+1, bet...@google.com wrote:
>
> Hi,
>
> In Python, I can include params like this:
>
> =
>
> *params = {'auth': ''}*
>
> response = requests.request("GET", url, data=payload, headers=headers, 
> *params=params*)
>
> =
>
> Any pointers on how Golang does this?
>
> Thanks,
> Betsy
>

-- 
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] Evaluation order

[Ian Lance Taylor]

On Tue, Dec 13, 2016 at 6:46 AM, Jesper Louis Andersen
 wrote:
> On Tue, Dec 13, 2016 at 2:57 PM Rafał Jęczalik 
> wrote:
>>
>> Hey Gophers!
>>
>> Does the spec guarantees the following program will always output "3 2"?
>>
>
> Yes. f() is in funcall context, and there the order is lexicographic
> left-to-right as the specification says.

I'm sorry, I don't agree.  It's clear that the first value printed
will always be 3.  But the spec does not guarantee when the second
argument to p is evaluated.  It may be evaluated before call of f, in
which case the program will print 1, or it may be evaluated after the
call of f, in which case the program will print 2.  The spec does not
actually say that all function call arguments are evaluated in left to
right order.  It says that among the arguments, all function calls,
method calls, and communication expressions are evaluated in left to
right order.  That is not quite the same thing.

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] Is there a tool or a library that lets me typecheck Go programs?

[adonovan via golang-nuts]

On Monday, 12 December 2016 12:22:51 UTC-5, Jan Mercl wrote:
>
> On Mon, Dec 12, 2016 at 6:20 PM  wrote:
>
> > I realize that obviously the Go compiler does it, I was wondering if 
> there is a good API for that I can use, like the ast package?
>
> See https://golang.org/pkg/go/types/
>

You can use go/types directly if you just want to type-check a single file, 
but all but the most trivial Go programs import other packages.  You have 
three choices for how to handle import declarations:
(1) ignore them
(2) load type information for exported packages from .a files produced by 
the compiler
(3) load the entire program from source.

The vet command takes approach #1, which of course means that it has 
incomplete information.  To use approach #2, you need to use the 
go/importer package, and furthermore rely on all the relevant .a files 
being up to date (which they rarely are).  For approach #3, you need to use 
the golang.org/x/tools/go/loader package, which loads, parses, and 
type-checks all the source code for a multi-package program laid out 
according to 'go build' conventions.  Look at any of several tools in that 
repository for an example of how to put the pieces together.  For example, 
with no flags, ssadump simply type-checks the specified packages:

$ go get golang.org/x/tools/cmd/ssadump
$ cat a.go
package main
var x int = "string"
$ ssadump a.go
a.go:2:13: cannot convert "string" (untyped string constant) to int

There's an in-depth tutorial for the go/types package here: 
https://github.com/golang/example/tree/master/gotypes

-- 
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] Evaluation order

[Jesper Louis Andersen]

On Tue, Dec 13, 2016 at 2:57 PM Rafał Jęczalik 
wrote:

> Hey Gophers!
>
> Does the spec guarantees the following program will always output "3 2"?
>
>
Yes. f() is in funcall context, and there the order is lexicographic
left-to-right as the specification says.

-- 
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: CPU scheduler on Xeon

[Stannis Kozlov]

Got it!
Thanks

On Tue, Dec 13, 2016 at 11:35 AM, Dave Cheney  wrote:

>
>
> On Tuesday, 13 December 2016 19:20:04 UTC+11, Stannis Kozlov wrote:
>>
>> Thanks for reply, Dave
>>
>> I've made simple application and run it on Xeon and i5. In case of i5 I
>> see threads as expected, on Xeon CPU only one thread is working. May it
>> related with difference go versions?
>>
>
> yes, this is why.
>
> Before Go 1.5, Go defaulted to one CPU by default. https://golang.org/
> doc/go1.5
>
> You should upgrade to Go 1.7.4 and prepare to upgrade to Go 1.8 early next
> year. You are using ancient and unsupported versions of Go.
> https://github.com/golang/go/wiki/Go-Release-Cycle#release-maintenance
>
>
>>
>> i5 output (go version 1.6):
>> $ go run test_tr.go
>> Spinning thread
>> Spinning thread
>> Spinning thread
>> Spinning thread
>> Spinning thread
>> Thread: 4
>> Thread: 1
>> Thread: 0
>> Thread: 2
>>
>>
>> Xeon output (go version 1.2.1):
>> $ go run test_tr.go
>> Spinning thread
>> Thread: 0
>> ^Cexit status 2
>>
>>
>>
>>
>> Code listing:
>> package main
>>
>>
>> import (
>>  "fmt"
>>  "math"
>>  "sync"
>> )
>>
>>
>> func A1(z int, wg *sync.WaitGroup) {
>>  fmt.Printf("Thread: %v\n",z)
>>  var m, k float64 = 9.9,9.99
>>  var i float64
>>  for i = 0.0; i < 100; i++ {
>>  math.Sqrt(float64(m*i + k*i))
>>  }
>>  wg.Done()
>> }
>>
>>
>> func main() {
>>  var wg sync.WaitGroup
>>  for i := 0; i < 5; i++ {
>>  wg.Add(1)
>>  go A1(i, )
>>  fmt.Println("Spinning thread")
>>  }
>>  wg.Wait()
>> }
>>
>>
>> On Tuesday, December 13, 2016 at 12:56:50 AM UTC+3, Dave Cheney wrote:
>>>
>>> There are no settings to affect the scheduler save GOMAXPROCS. Check
>>> that none of your code or your dependencies are calling runtime.GOMAXPROCS.
>>>
>>> If that doesn't help, try profiling your application, the cpu or block
>>> profile might tell you where your program is hitting a point of contention.
>>>
>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/bh_FPjPCu-M/unsubscribe.
> To unsubscribe from this group and all its topics, 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] json unmarshal automatic type conversion issue

[arunkumar]

Hi gophers,

How to prevent json unmarshal from type conversion. From the below sample 
code i got the input string converted to float64


package main

import (
"fmt"
"encoding/json"
"reflect"
)

func main() {
var output interface{}
var input = "1"
fmt.Println(reflect.TypeOf(input))
json.Unmarshal([]byte(input), )
fmt.Println(reflect.TypeOf(output)) 
}


-- 

--
IMPORTANT: This is an e-mail from HiFX IT Media Services Pvt. Ltd. Its 
content are confidential to the intended recipient. If you are not the 
intended recipient, be advised that you have received this e-mail in error 
and that any use, dissemination, forwarding, printing or copying of this 
e-mail is strictly prohibited. It may not be disclosed to or used by anyone 
other than its intended recipient, nor may it be copied in any way. If 
received in error, please email a reply to the sender, then delete it from 
your system. 

Although this e-mail has been scanned for viruses, HiFX cannot ultimately 
accept any responsibility for viruses and it is your responsibility to scan 
attachments (if any).

​
Before you print this email or attachments, please consider the negative 
environmental impacts associated with printing.

-- 
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] net/http best way to get request/response header size

[kaitoY Kors]

Hello,

In the current implementation of net/http and net/textproto, other than 
iterating all the key/value pairs of Header, type map[string][]string, is 
there any other way to get the total size effectively?
The concern is if the header contains lots of key/value pairs, it might be 
inefficient to get the size by walking through the map.

Any advice/comment is appreciated.
Thanks in advance

-- 
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] Evaluation order

[Rafał Jęczalik]

Hey Gophers!

Does the spec guarantees the following program will always output "3 2"?

https://play.golang.org/p/InTOwJIPmD

>From what I read [0] only evaluation order of expressions inside slice or 
map definitions or indexing on those values is unspecified?

--
Rafal

[0] https://golang.org/ref/spec#Order_of_evaluation, this part in 
particular:

"However, the order of those events compared to the evaluation and indexing 
of x and the evaluation of y is not specified."

-- 
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] Code-base Refactoring Tool for Go , Move files from packages to sub packages

[jishnu]

http://stackoverflow.com/questions/41121448/code-base-refactoring-tool-for-go-move-files-from-packages-to-sub-packages

Currently my code-base have just 1 level of packages , due to the increase 
in number of components it would make much sense if I use sub packages.Is 
there any code refactoring tools I could use to achieve this.

Package_1/
  -- File 1
  -- File 2
  -- File 3
  -- File 4Package_2/
  -- File 5
  -- File 6
  -- File 7

Target structure

Package_1
  /subpackage1
   -- File 1
   -- File 2
  /subpackage2
   -- File 3
   -- File 4Package_2/
   /subpackage3
   -- File 5
   -- File 6
   /subpackage4
   -- File 4  

I tried *gomvpkg* https://godoc.org/golang.org/x/tools/cmd/gomvpkg but 
doesnot support moving files from same package to different package.

-- 

--
IMPORTANT: This is an e-mail from HiFX IT Media Services Pvt. Ltd. Its 
content are confidential to the intended recipient. If you are not the 
intended recipient, be advised that you have received this e-mail in error 
and that any use, dissemination, forwarding, printing or copying of this 
e-mail is strictly prohibited. It may not be disclosed to or used by anyone 
other than its intended recipient, nor may it be copied in any way. If 
received in error, please email a reply to the sender, then delete it from 
your system. 

Although this e-mail has been scanned for viruses, HiFX cannot ultimately 
accept any responsibility for viruses and it is your responsibility to scan 
attachments (if any).

​
Before you print this email or attachments, please consider the negative 
environmental impacts associated with printing.

-- 
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] Should I return a value or pointer?

['Russ Cox' via golang-nuts]

In the very old days, errors.New was spelled os.NewError, and it returned
an os.errorString, not an , and so those error
implementations did compare by string value. Arranging for the pointer to
be used instead was done explicitly so that errors.New called with the same
text from multiple packages didn't end up accidentally returning equal
results. For example if you have (somewhat artificially)

package json
var ErrInvalid = errors.New("invalid argument")

package strings
func Something(s string) error { ... return errors.New("invalid
argument") ... }

then it's at least a bit confusing that you might compare the result of
strings.Something(s) to json.ErrInvalid and find they are equal.

The API question was the most important deciding factor, but of course a
pointer comparison is cheaper than a string comparison, and errors are
compared for equality all the time, so that's nice to make cheaper.

Russ


On Tue, Dec 13, 2016 at 8:17 AM, Jon  wrote:

> Thanks for the thorough answer! I think you answered my question. The
> errors package was the simplest piece of code I could find where it didn't
> seem to matter whether a value or pointer was passed so I wanted to know
> why a pointer was passed instead of a value.
>
> As you mentioned twice now (with proof
> )
> it did matter that a pointer was passed and the time package is likely a
> great counter example where Time is retuned as a value instead of pointer
> from time.New. (I'm now interested to know why time.New does this. I
> believe I read an explanation some time ago which I'll search for.)
>
> I don't have a specific semantic problem per se – I just wanted to learn
> more about some nuances/uses of the language and you helped greatly. Thanks!
>
> On Tuesday, 13 December 2016 12:36:17 UTC, Axel Wagner wrote:
>
>> On Tue, Dec 13, 2016 at 10:48 AM, Jon  wrote:
>>
>>> Axel, that's an interesting thought on why errors.New() returns a
>>>  However, I would argue that being able to do
>>> errors.New("foo") == errors.New("foo") could be seen as a feature by some
>>> people to break dependencies
>>>
>>
>> Well, not by the authors of the errors package, apparently :)
>>
>> Also note, that there is a common adage about not comparing error
>> strings. I'd also argue, that this is confusing:
>> return fmt.Errorf("foo failed: %s", v)
>> In some instances this could be seen as "the same error", even with
>> different v, in other instances not. I believe it's better to be explicit
>> about this and not depend on the error-message; the error-message is for
>> humans to read, not for computers to distinguish (I mean, if nothing else,
>> comparing strings is less efficient than comparing a pointer).
>>
>>
>>
>>> Therefore I am not quite convinced this is the sole reason why
>>> {} is returned instead of errorString{}.
>>>
>>
>> Allow me to convince you, then: https://github.com/golan
>> g/go/blob/master/src/errors/errors_test.go#L14
>> 
>> It's clearly a requirement chosen by the author of the package (which is
>> rsc, btw, who I CC'ed). And I, at least, can't think of a better way to
>> achieve this requirement.
>>
>> In case any one else reads this, this question/discussion isn't really
>>> about the errors package it's about what to return from a New function if
>>> you need similar functionality to the errors package.
>>>
>>
>> I think you should be more precise, than "similar functionality". The
>> errors package is special, as we've discussed here, in that it has very
>> specific semantics about how equality works. If you want the same semantics
>> then do the same thing. If you don't want those semantics, don't do it :)
>>
>> I mean, regardless of whether you believe that the semantics where
>> *intended*, those are the semantics that you'll *get* (and AFAIK they're
>> the most sensible way to get them), so you should work from that.
>>
>> You could also look at time.Time, which has different semantics (it's a
>> small struct, but it's supposed to be passed around by value and you need
>> to be aware of the used *time.Location when comparing (and use Before/After
>> if you are interested in the instant in time).
>>
>> There are tons of other examples, each with their own specific semantic.
>> Knowing what the semantics are, that you are going for, would be helpful
>> here :)
>>
>>
>>> I want to know what the thought process was behind returning a
>>> {} from errors.New instead of errorString{} or even 'type
>>> errorString string'.
>>>
>>> On Saturday, 10 December 2016 22:13:16 UTC, Axel Wagner wrote:



 On Sat, Dec 10, 2016 at 8:10 PM, Jon  wrote:

> I would like to know what my default practice should be when 

[go-nuts] Re: SQLite3 Support without CGo

[sam]

If anyone is interested, I've opened a ticket on GitHub 
(https://github.com/golang/go/issues/18296).

Please drop by and show your support.

On Monday, December 12, 2016 at 11:28:19 PM UTC, brainman wrote:
>
> I was toying with this idea myself.
>
> Maybe even going all the way with "pure" Go version - with something 
> similar to https://github.com/nkbai/go-memorydll :-)
>
> 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] Should I return a value or pointer?

[Jon]

Thanks for the thorough answer! I think you answered my question. The 
errors package was the simplest piece of code I could find where it didn't 
seem to matter whether a value or pointer was passed so I wanted to know 
why a pointer was passed instead of a value.

As you mentioned twice now (with proof 
) 
it did matter that a pointer was passed and the time package is likely a 
great counter example where Time is retuned as a value instead of pointer 
from time.New. (I'm now interested to know why time.New does this. I 
believe I read an explanation some time ago which I'll search for.)

I don't have a specific semantic problem per se – I just wanted to learn 
more about some nuances/uses of the language and you helped greatly. Thanks!

On Tuesday, 13 December 2016 12:36:17 UTC, Axel Wagner wrote:
>
> On Tue, Dec 13, 2016 at 10:48 AM, Jon  > wrote:
>
>> Axel, that's an interesting thought on why errors.New() returns a 
>>  However, I would argue that being able to do 
>> errors.New("foo") == errors.New("foo") could be seen as a feature by some 
>> people to break dependencies
>>
>
> Well, not by the authors of the errors package, apparently :)
>
> Also note, that there is a common adage about not comparing error strings. 
> I'd also argue, that this is confusing:
> return fmt.Errorf("foo failed: %s", v)
> In some instances this could be seen as "the same error", even with 
> different v, in other instances not. I believe it's better to be explicit 
> about this and not depend on the error-message; the error-message is for 
> humans to read, not for computers to distinguish (I mean, if nothing else, 
> comparing strings is less efficient than comparing a pointer).
>
>  
>
>> Therefore I am not quite convinced this is the sole reason why 
>> {} is returned instead of errorString{}.
>>
>
> Allow me to convince you, then: 
> https://github.com/golang/go/blob/master/src/errors/errors_test.go#L14 
> 
> It's clearly a requirement chosen by the author of the package (which is 
> rsc, btw, who I CC'ed). And I, at least, can't think of a better way to 
> achieve this requirement.
>
> In case any one else reads this, this question/discussion isn't really 
>> about the errors package it's about what to return from a New function if 
>> you need similar functionality to the errors package.
>>
>
> I think you should be more precise, than "similar functionality". The 
> errors package is special, as we've discussed here, in that it has very 
> specific semantics about how equality works. If you want the same semantics 
> then do the same thing. If you don't want those semantics, don't do it :)
>
> I mean, regardless of whether you believe that the semantics where 
> *intended*, those are the semantics that you'll *get* (and AFAIK they're 
> the most sensible way to get them), so you should work from that.
>
> You could also look at time.Time, which has different semantics (it's a 
> small struct, but it's supposed to be passed around by value and you need 
> to be aware of the used *time.Location when comparing (and use Before/After 
> if you are interested in the instant in time).
>
> There are tons of other examples, each with their own specific semantic. 
> Knowing what the semantics are, that you are going for, would be helpful 
> here :)
>  
>
>> I want to know what the thought process was behind returning a 
>> {} from errors.New instead of errorString{} or even 'type 
>> errorString string'.
>>
>> On Saturday, 10 December 2016 22:13:16 UTC, Axel Wagner wrote:
>>>
>>>
>>>
>>> On Sat, Dec 10, 2016 at 8:10 PM, Jon  wrote:
>>>
 I would like to know what my default practice should be when returning 
 structs from functions. Should I return a value or a pointer? (Assume I 
 don't need the functionality of returning a pointer and my struct contains 
 at most one simple field so a vast copy isn't needed if I return a value.)

 A specific example could be the errors package 
  with errors.New. 

 The New function is implemented by returning an errorString pointer: 
 

 func New(text string) error {
 return {text}
 }

 Could it just as easily have been implemented by returning an errorString 
 value ? If so why was the 
 pointer return chosen over value return?

>>>
>>> Because that way
>>> errors.New("foo") != errors.New("foo")
>>> This means, that if two packages were to define errors with the same 
>>> message by coincidence, they wouldn't get mixed up.
>>>
>>>
 func New(text string) error {
 return errorString{text}
 }

 

Re: [go-nuts] Function scoped method receivers

[roger peppe]

On 13 December 2016 at 01:08, go-question  wrote:
>
> I noticed that its possible to define/scope types/interfaces in functions.
>
> Now I'm not arguing that this is good practice, but for the sake of
> curiosity.
> How can I then add a method w/ a receiver to type foo so that it satisfies
> interface ifoo? (in function scope)
>
>
> func main() {
>
> type foo struct{
> a string
> }
>
> type ifoo interface {
> Bar()
> }
>
> // possible?
> foo{"baz"}.Bar()
>
> }

Technically you can do it (you can make a program that will compile,
demonstrating that your type does satisfy the interface)
but it's not very useful because it'll crash when you call the method :-)

package main

func main() {
type ifoo interface {
Bar()
}
type foo struct {
ifoo
a string
}
// Yup, it's possible, but it's probably not what you want.
foo{a: "baz"}.Bar()
}


This is still a useful technique in some circumstances though (for example
if there's a large interface that I want to mock only a small portion of,
I can embed the interface and define only those methods I expect to be called).

Another useful technique when you want function-scoped methods is this:

package main

import "fmt"

type ifoo interface {
Bar()
}

type ifooFuncs struct {
bar func()
// ... and another function-typed field for each method.
}

func (f ifooFuncs) Bar() {
f.bar()
}

func main() {
x := ifooFuncs{
bar: func() {
fmt.Println("bar")
},
}
x.Bar()
}

-- 
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] Should I return a value or pointer?

['Axel Wagner' via golang-nuts]

On Tue, Dec 13, 2016 at 10:48 AM, Jon  wrote:

> Axel, that's an interesting thought on why errors.New() returns a
>  However, I would argue that being able to do
> errors.New("foo") == errors.New("foo") could be seen as a feature by some
> people to break dependencies
>

Well, not by the authors of the errors package, apparently :)

Also note, that there is a common adage about not comparing error strings.
I'd also argue, that this is confusing:
return fmt.Errorf("foo failed: %s", v)
In some instances this could be seen as "the same error", even with
different v, in other instances not. I believe it's better to be explicit
about this and not depend on the error-message; the error-message is for
humans to read, not for computers to distinguish (I mean, if nothing else,
comparing strings is less efficient than comparing a pointer).



> Therefore I am not quite convinced this is the sole reason why
> {} is returned instead of errorString{}.
>

Allow me to convince you, then:
https://github.com/golang/go/blob/master/src/errors/errors_test.go#L14
It's clearly a requirement chosen by the author of the package (which is
rsc, btw, who I CC'ed). And I, at least, can't think of a better way to
achieve this requirement.

In case any one else reads this, this question/discussion isn't really
> about the errors package it's about what to return from a New function if
> you need similar functionality to the errors package.
>

I think you should be more precise, than "similar functionality". The
errors package is special, as we've discussed here, in that it has very
specific semantics about how equality works. If you want the same semantics
then do the same thing. If you don't want those semantics, don't do it :)

I mean, regardless of whether you believe that the semantics where
*intended*, those are the semantics that you'll *get* (and AFAIK they're
the most sensible way to get them), so you should work from that.

You could also look at time.Time, which has different semantics (it's a
small struct, but it's supposed to be passed around by value and you need
to be aware of the used *time.Location when comparing (and use Before/After
if you are interested in the instant in time).

There are tons of other examples, each with their own specific semantic.
Knowing what the semantics are, that you are going for, would be helpful
here :)


> I want to know what the thought process was behind returning a
> {} from errors.New instead of errorString{} or even 'type
> errorString string'.
>
> On Saturday, 10 December 2016 22:13:16 UTC, Axel Wagner wrote:
>>
>>
>>
>> On Sat, Dec 10, 2016 at 8:10 PM, Jon  wrote:
>>
>>> I would like to know what my default practice should be when returning
>>> structs from functions. Should I return a value or a pointer? (Assume I
>>> don't need the functionality of returning a pointer and my struct contains
>>> at most one simple field so a vast copy isn't needed if I return a value.)
>>>
>>> A specific example could be the errors package
>>>  with errors.New.
>>>
>>> The New function is implemented by returning an errorString pointer:
>>> 
>>>
>>> func New(text string) error {
>>> return {text}
>>> }
>>>
>>> Could it just as easily have been implemented by returning an errorString
>>> value ? If so why was the pointer
>>> return chosen over value return?
>>>
>>
>> Because that way
>> errors.New("foo") != errors.New("foo")
>> This means, that if two packages were to define errors with the same
>> message by coincidence, they wouldn't get mixed up.
>>
>>
>>> func New(text string) error {
>>> return errorString{text}
>>> }
>>>
>>> Could it also have been implemented as below
>>>  which looks even simpler?
>>>
>>> func New(text string) error {
>>> return errorString(text)
>>> }
>>> // errorString is a trivial implementation of error.
>>> type errorString string
>>>
>>> func (e errorString) Error() string {
>>> return string(e)
>>> }
>>>
>>> What was the thought process that went into the implementation of the
>>> errors package? Were the latter two implementation options I suggest
>>> considered? If so why were they disregarded? Performance? Coding standards?
>>> Heap allocation benefits?
>>>
>>> --
>>> 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...@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 

Re: [go-nuts] Re: invitation to gophers.slack.com

[Damian Gryski]

On Friday, December 9, 2016 at 4:16:45 PM UTC+1, Ian Davis wrote:
>
> As an aside, does anyone know if there are publicly available chatlogs 
> from the slack channel?
>
>
There are not.  You must be a member of the Gophers Slack to see the 
message achive.

Damian 

-- 
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: CPU scheduler on Xeon

[Dave Cheney]

On Tuesday, 13 December 2016 19:20:04 UTC+11, Stannis Kozlov wrote:
>
> Thanks for reply, Dave
>
> I've made simple application and run it on Xeon and i5. In case of i5 I 
> see threads as expected, on Xeon CPU only one thread is working. May it 
> related with difference go versions? 
>

yes, this is why.

Before Go 1.5, Go defaulted to one CPU by 
default. https://golang.org/doc/go1.5

You should upgrade to Go 1.7.4 and prepare to upgrade to Go 1.8 early next 
year. You are using ancient and unsupported versions of 
Go. https://github.com/golang/go/wiki/Go-Release-Cycle#release-maintenance
 

>
> i5 output (go version 1.6):
> $ go run test_tr.go 
> Spinning thread
> Spinning thread
> Spinning thread
> Spinning thread
> Spinning thread
> Thread: 4
> Thread: 1
> Thread: 0
> Thread: 2
>
>
> Xeon output (go version 1.2.1):
> $ go run test_tr.go 
> Spinning thread
> Thread: 0
> ^Cexit status 2
>
>
>
>
> Code listing:
> package main
>
>
> import (
>  "fmt"
>  "math"
>  "sync"
> )
>
>
> func A1(z int, wg *sync.WaitGroup) {
>  fmt.Printf("Thread: %v\n",z)
>  var m, k float64 = 9.9,9.99
>  var i float64
>  for i = 0.0; i < 100; i++ {
>  math.Sqrt(float64(m*i + k*i))
>  }
>  wg.Done()
> }
>
>
> func main() {
>  var wg sync.WaitGroup
>  for i := 0; i < 5; i++ {
>  wg.Add(1)
>  go A1(i, )
>  fmt.Println("Spinning thread")
>  }
>  wg.Wait()
> }
>
>
> On Tuesday, December 13, 2016 at 12:56:50 AM UTC+3, Dave Cheney wrote:
>>
>> There are no settings to affect the scheduler save GOMAXPROCS. Check that 
>> none of your code or your dependencies are calling runtime.GOMAXPROCS.
>>
>> If that doesn't help, try profiling your application, the cpu or block 
>> profile might tell you where your program is hitting a point of contention. 
>>
>>

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