Re: [go-nuts] []byte to func

[Basile Starynkevitch]

On Tuesday, March 21, 2017 at 4:04:34 AM UTC+1, Rob 'Commander' Pike wrote:
>
> No, Go does not have run-time evaluation of Go program source. It is 
> strictly a compiled language, although there are some (pieces of) 
> interpreters out there.
>
>
>
However, Go 1.8 has plugins  (on Linux 
x86-64 at least). A possible way -which can also be used in C, C++, Ocaml, 
etc...- might be to generate (at *runtime* of your program) some Go code in 
some *temporary* /tmp/generatedsrc.go file (actually using ioutils/TempFile 
 to get it), then run (using 
functions from os/exec  package) some 
compilation command to compile that source into a /tmp/generatedsrc.so 
shared library plugin, and Open  
that plugin, then Lookup  
some symbol there and use a type assertion 
 to convert it to some 
functional value, that could be called later.

I confess that I don't know yet exactly how to do that in a convenient and 
robust way (you want the compilation of the plugin to be minimal and quick, 
even if it uses most packages of the main program). I have started using Go 
only once it had plugins because of that issue. The issue is plugins and 
packages . 
Another issue is what exact compilation command should be used (I suspect 
that passing -linkshared with -buildmode=plugin to the go build compilation 
command is needed).  I have asked a question about plugins and packages 
 (you 
probably don't want the plugin to incorporate all the packages of the main 
program that it is using). It would be nice if some Go plugin guru could 
explain more how to do that.

Cheers

-- 
Basile Starynkevitch  (France)

-- 
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] []byte to func

[Sandeep Kalra]

Thanks Harley.

I will pick your example and will see if this is do-able...


Sandeep


Best Regards,
Sandeep Kalra


On Mon, Mar 20, 2017 at 11:48 PM, Harley Laue 
wrote:

> I have some code that I've sat on for some time:
>
> type Cell int
> type Function func() error
>
> func cellToFunction(c Cell) *Function {
> p := unsafe.Pointer(uintptr(c))
> if p == nil { return nil }
> return (*Function)(p)
> }
>
> func functionToCell(w *Function) Cell {
> return Cell(uintptr(unsafe.Pointer(w)))
> }
>
> It's not []byte, but the idea is similar. There are a few major gotchas.
> After functionToCell, it's possible for the function to be garbage
> collected. The function type must be known ahead of time for
> cellToFunction. There's no way that I know to get arbitrary functions.
>
> Honestly, this approach is fragile and error prone, but it is possible.
>
>
> On Mon, Mar 20, 2017, 7:57 PM Sandeep Kalra 
> wrote:
>
>> Is there any option to convert []byte to func  (Assuming that []byte
>> carries valid function)
>> 
>> package main
>>
>> import (
>> "fmt"
>> "io/ioutil"
>> )
>>
>> func run(b []byte) {
>> /// HERE ?
>> }
>>
>> func main() {
>> if b, e := ioutil.ReadFile("./file.go"); e != nil {
>> fmt.Println(e)
>> } else {
>> run(b)
>> }
>> }
>>
>> --
>> 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: Unmarshalling JSON from MongoDB serverStatus in Go - how to handle nesting, and easy retrieval?

[kumargv]

hi ,

I am also having the same problem, can you please elaborate 

invalid operation: dat["connections"]["current"] (type interface {} does 
not support indexing)

Thanks 

On Friday, August 21, 2015 at 4:22:22 PM UTC+5:30, Giulio Iotti wrote:
>
> On Friday, August 21, 2015 at 11:51:32 AM UTC+2, Victor Hooi wrote:
>>
>> [...]
>> However, the following will not work:
>>
>> fmt.Println(dat["connections"]["current"])
>>
>>
>> I get:
>>
>>
>> ./parse_serverstatus.go:37: invalid operation: 
>>> dat["connections"]["current"] (type interface {} does not support indexing)
>>
>>
>> The thing is, not every field is nested to to the same depth.
>>
>>
>> Question 1 - Is there a way to unmarshall the above JSON, and have Go 
>> "magically" handle the types, and still allow me to access them afterwards 
>> as a normal map?
>>
>
> No, there is no magic. But there is a pretty neat syntax, a type switch: 
> https://golang.org/doc/effective_go.html#type_switch
>
> So in your case, asset that dat["connections"] is a map; it is, get 
> "current", otherwise...
>  
>
>> (For context, in Python, I'm just using "server_status_json = 
>> json.loads(line)", and it all pretty much works as you'd expect).
>>
>
> Yes, but Python has a different view of types ;)
>  
>
>> Question 2 - Is there a way to store a mapping of names, to locations, 
>> such that I can access metrics easily?
>>
>>
>> For example, in the Python version I have:
>>
>>
>> def get_nested_items(obj, *names):
>>> """Return obj[name][name2] ... [nameN] for any list of names."""
>>> for name in names:
>>> obj = obj[name]
>>> return obj
>>> metrics_to_extract = {
>>> 'available_connections': ['connections', 'available'],
>>> 'current_connections': ['connections', 'current']
>>> }
>>> for key, names in metrics_to_extract.items():
>>> value = get_nested_items(server_status_json, *names)
>>> json_points.append(create_point(key, value, timestamp, tags))
>>
>>
>> In this case, metrics_to_extract has the name and locations, and I just 
>> iterate over that and add them to my output (json_points).
>>
>> (Originally I was using locations like 
>> "server_status_json['connections']['current']" along with eval(), which 
>> wasn't the best).
>>
>> What's the idiomatic way of doing this in Go?
>>
>
> Wherever you have a map of constant keys in Python, make a struct in Go. 
> Then you can have a slice of structs (pointers).
>  
>
>> Question 3 - One other complication is that sometimes, some of the float 
>> fields get wrapped in a "floatApprox" - e.g.:
>>
>> "connections": {
>>>   "current": 131,
>>>   "available": 51069,
>>>   "totalCreated": {
>>> "floatApprox": 177400
>>>   }
>>> },
>>
>>
>> What's a clean way of handling this? Would you just try and access the 
>> location, and if it failed, try again but adding one level of floatApprox 
>> nesting - does that sound reasonable?
>>
>
> As above, you need type assertions. Ask again if you want examples of more 
> clarifications!
>
> -- 
> Giulio
> https://twitter.com/dullboy
>

-- 
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] []byte to func

[Harley Laue]

I have some code that I've sat on for some time:

type Cell int
type Function func() error

func cellToFunction(c Cell) *Function {
p := unsafe.Pointer(uintptr(c))
if p == nil { return nil }
return (*Function)(p)
}

func functionToCell(w *Function) Cell {
return Cell(uintptr(unsafe.Pointer(w)))
}

It's not []byte, but the idea is similar. There are a few major gotchas.
After functionToCell, it's possible for the function to be garbage
collected. The function type must be known ahead of time for
cellToFunction. There's no way that I know to get arbitrary functions.

Honestly, this approach is fragile and error prone, but it is possible.


On Mon, Mar 20, 2017, 7:57 PM Sandeep Kalra  wrote:

> Is there any option to convert []byte to func  (Assuming that []byte
> carries valid function)
> 
> package main
>
> import (
> "fmt"
> "io/ioutil"
> )
>
> func run(b []byte) {
> /// HERE ?
> }
>
> func main() {
> if b, e := ioutil.ReadFile("./file.go"); e != nil {
> fmt.Println(e)
> } else {
> run(b)
> }
> }
>
> --
> 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] []byte to func

[Sandeep Kalra]

Thanks Rob!

On Monday, March 20, 2017 at 10:04:34 PM UTC-5, Rob 'Commander' Pike wrote:
>
> No, Go does not have run-time evaluation of Go program source. It is 
> strictly a compiled language, although there are some (pieces of) 
> interpreters out there.
>
> -rob
>
>
> On Mon, Mar 20, 2017 at 7:57 PM, Sandeep Kalra  > wrote:
>
>> Is there any option to convert []byte to func  (Assuming that []byte 
>> carries valid function)
>> 
>> package main
>>
>> import (
>> "fmt"
>> "io/ioutil"
>> )
>>
>> func run(b []byte) {
>> /// HERE ?
>> }
>>
>> func main() {
>> if b, e := ioutil.ReadFile("./file.go"); e != nil {
>> fmt.Println(e)
>> } else {
>> run(b)
>> }
>> }
>>
>> -- 
>> 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] []byte to func

[Rob Pike]

No, Go does not have run-time evaluation of Go program source. It is
strictly a compiled language, although there are some (pieces of)
interpreters out there.

-rob


On Mon, Mar 20, 2017 at 7:57 PM, Sandeep Kalra 
wrote:

> Is there any option to convert []byte to func  (Assuming that []byte
> carries valid function)
> 
> package main
>
> import (
> "fmt"
> "io/ioutil"
> )
>
> func run(b []byte) {
> /// HERE ?
> }
>
> func main() {
> if b, e := ioutil.ReadFile("./file.go"); e != nil {
> fmt.Println(e)
> } else {
> run(b)
> }
> }
>
> --
> 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] []byte to func

[Sandeep Kalra]

Is there any option to convert []byte to func  (Assuming that []byte 
carries valid function)

package main

import (
"fmt"
"io/ioutil"
)

func run(b []byte) {
/// HERE ?
}

func main() {
if b, e := ioutil.ReadFile("./file.go"); e != nil {
fmt.Println(e)
} else {
run(b)
}
}

-- 
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] Inspecting a function for its arguments with reflection

[Marian Kopriva]

Check out https://github.com/go-martini/martini if you're looking for some 
magic.
In case you don't find any magic there, then i'm sorry, i've havne't used 
martini myself, and am not familiar with its source, i've only heard from 
others that it's quite magicky.

-- 
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: Inspecting a function for its arguments with reflection

[Marian Kopriva]

What you're looking for is reflect.Type.NumIn()int and reflect.Type.In(i 
int) Type.
See example here https://play.golang.org/p/q1D56Abj-5


On Tuesday, March 21, 2017 at 12:01:09 AM UTC+1, Tyler Compton wrote:
>
> I'm trying to create an HTTP request router library that automatically 
> decodes parameters in the request URL and passes them as arguments to the 
> handler function. It would theoretically make something like this possible:
>
> myRouter.HandleFunc("/getPuppies/{id}", func(w http.ResponseWriter, r *
> http.Request, id string) {
> // Handle the request
> });
>
> I am aware that you can't get the name of a function's arguments. That's 
> okay with me, I can just pass the params in the order they appear. However, 
> I do need to be able to check how many arguments a function has and what 
> the types of those arguments are, so I can type assert the parameters and 
> give sane error messages when the user makes a mistake.
>
> Before you point out that this is a bad idea and that reflection is never 
> clear, I am fully aware! I'm doing this to learn about reflection in Go and 
> to see if Go can support a workflow something like Java's JAX-RS.
>

-- 
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/link problems with gccgo

[Richard D'Addio]

Ok thanks I saw that post but didn't read down far enough, I am using 
golang v1.8 and GCC-7.0 and most of the refs in that post were golang v1.6 
and GCC-6.x. At the tail end there was some refs to golang v1.7  as 
you say. Issue has been around for almost a year I guess. 

Ended up switching to gc don't have the cycles to contrib to a fix right 
now. Hate to do that, I have been a GCC user for years. 

Thanks again for your help.

BR,

Rich

On Monday, March 20, 2017 at 7:26:41 PM UTC-4, Ian Lance Taylor wrote:
>
> On Mon, Mar 20, 2017 at 4:25 PM, Ian Lance Taylor  > wrote: 
> > On Mon, Mar 20, 2017 at 4:17 PM, Richard D'Addio  > wrote: 
> >> With gccgo I get the following error the same builds fine with gc: 
> >> 
> >> //with native 
> >> 
> >> 
> /home/rdaddio/mynewclient/clone_gobotics/gobotics/go/pkg/tool/linux_amd64/compile
>  
>
> >> -o $WORK/github.com/hashicorp/go-multierror.a -trimpath $WORK -p 
> >> github.com/hashicorp/go-multierror -complete -buildid 
> >> e777c32e05670dbca9940409bba89b18504d68f5 -importmap 
> >> 
> github.com/hashicorp/errwrap=github.com/hashicorp/go-multierror/vendor/github.com/hashicorp/errwrap
>  
> >> -D 
> >> _/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/
> github.com/hashicorp/go-multierror 
> >> -I $WORK -I 
> >> /home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/pkg/linux_amd64 
> -pack 
> >> ./append.go ./flatten.go ./format.go ./multierror.go ./prefix.go 
> >> 
> >> 
> >> //with gccgo option 
> >> 
> >> /home/rdaddio/myGCC_run/myGCC_out/bin/gccgo -I $WORK -I 
> >> 
> /home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/pkg/gccgo_linux_amd64 
> >> -c -g -m64 -fgo-pkgpath=github.com/hashicorp/go-multierror 
> >> 
> -fgo-relative-import-path=_/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/
> github.com/hashicorp/go-multierror 
> >> -o $WORK/github.com/hashicorp/go-multierror/_obj/_go_.o ./append.go 
> >> ./flatten.go ./format.go ./multierror.go ./prefix.go 
> >> 
> >> mkdir -p $WORK/github.com/pkg/ 
> >> 
> >> cd 
> >> /home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/
> github.com/pkg/errors 
> >> 
> >> /home/rdaddio/myGCC_run/myGCC_out/bin/gccgo -I $WORK -c -g -m64 
> >> -fgo-pkgpath=github.com/pkg/errors 
> >> 
> -fgo-relative-import-path=_/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/
> github.com/pkg/errors 
> >> -o $WORK/github.com/pkg/errors/_obj/_go_.o ./errors.go ./stack.go 
> >> 
> >> # github.com/hashicorp/go-multierror 
> >> 
> >> lib/src/github.com/hashicorp/go-multierror/prefix.go:6:30: error: 
> import 
> >> file 'github.com/hashicorp/errwrap' not found 
> >> 
> >>   "github.com/hashicorp/errwrap" 
> >> 
> >>   ^ 
> >> 
> >> lib/src/github.com/hashicorp/go-multierror/prefix.go:30:20: error: 
> reference 
> >> to undefined name 'errwrap' 
> >> 
> >> err.Errors[i] = errwrap.Wrapf(format, e) 
> >> 
> >> ^ 
> >> 
> >> lib/src/github.com/hashicorp/go-multierror/prefix.go:35:10: error: 
> reference 
> >> to undefined name 'errwrap' 
> >> 
> >>return errwrap.Wrapf(format, err) 
> > 
> > 
> > Thanks.  It looks like there is a bug with the implementation of 
> > vendor directories when using -compiler=gccgo. 
>
> In fact it's already been reported as https://golang.org/issue/15628. 
>
> Ian 
>
>
> >> On Monday, March 20, 2017 at 6:53:53 PM UTC-4, Ian Lance Taylor wrote: 
> >>> 
> >>> On Mon, Mar 20, 2017 at 3:40 PM, Richard D'Addio  
> >>> wrote: 
> >>> > Sorry in advance if this is the wrong list for this. 
> >>> > 
> >>> > 
> >>> > I can build the gobot.io code below with the golang v1.8 and the 
> >>> > standard 
> >>> > compiler: 
> >>> > 
> >>> > go version go1.8 linux/amd64 
> >>> > 
> >>> > go build -work -x hello_blink.go 
> >>> > 
> >>> > 
> >>> > But when I try to build with the GCC option in the same scenario it 
> >>> > fails. I 
> >>> > am using GCC 
> >>> > 
> >>> > gccgo (GCC) 7.0.1 20170314 (experimental) which has go1.8 support & 
> all 
> >>> > paths are correct: 
> >>> > 
> >>> > go build -work -x -compiler gccgo hello_blink.go 
> >>> > 
> >>> > 
> >>> > It can't seem to find paths that the gc code found and this leads to 
> a 
> >>> > link 
> >>> > error. The problem is 
> >>> > 
> >>> > in a single file and if this file is commented out the code builds 
> and 
> >>> > runs. 
> >>> > Since this code is likely unused 
> >>> > 
> >>> > it might be that the native compiler is detecting that 
> automatically? 
> >>> > 
> >>> > 
> >>> > It didn't seem like any special options were needed to use the gccgo 
> >>> > compiler. I've used 
> >>> > 
> >>> > it elsewhere in a similar way (different go code of course) without 
> >>> > problems. 
> >>> 
> >>> You didn't tell us what actually happens.  How does it fail? 
> >>> 
> >>> Ian 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> Groups 
> >> "golang-nuts" group. 
> >> To unsubscribe from this group 

[go-nuts] Puzzled by a profiling result around allocations

[Harry B]

Hi,

As part of preparing an internal go talk to explain using strings vs bytes 
of the bufio.Scanner, I created two small samples 
https://play.golang.org/p/-TYycdHaPC and 
https://play.golang.org/p/L7W-jiaHdL , the only difference in the hot path 
is reducing the conversions from `[]byte` to `string` (later also avoids 
fmt module’s string conversions). Input being a 10 million line file. Match 
is only one line.

For the moment, ignore the fact that I am not checking for number of 
arguments, is doing unnecessary optimizations etc. I am trying to take a 
simple case to explain.

First version runs in 3 seconds, second in 2 seconds. For the slower 
version using `.Text()` 90+ percent of the time was in `syscall.Syscall` 
(under syscall.Read on the file) that I wasn’t expecting anything more than 
10% change. However, the second version shows a much bigger reduction in 
`syscall.Syscall`. How is that possible? I expected it to be faster, but 
not affect the time spend reading file.The exclusion of fmt was unnecessary 
since the number of matches will be very small. But that is probably not 
relevant here. I have run it multiple times and made sure file is cached.

Attached are the profile SVGs. You can also see that an entire branch of 
the execution has disappeared in the faster/second version.

I do understand the second has avoided the allocation of string via 
scanner.Text(), however, the output of  go build -gcflags "-m"  give me the 
following

// First version

> go build -gcflags "-m" grep_simple_re.go
# command-line-arguments
./grep_simple_re.go:17: inlining call to bufio.NewScanner
./grep_simple_re.go:19: inlining call to (*bufio.Scanner).Text
./grep_simple_re.go:17: fp escapes to heap
./grep_simple_re.go:19: string(bufio.s·2.token) escapes to heap
*./grep_simple_re.go:21: line escapes to heap*
./grep_simple_re.go:17: main  literal does not escape
./grep_simple_re.go:21: main ... argument does not escape
:1: leaking param: io.p
:1: leaking param: .this

// Second version
> go build -gcflags "-m" grep_simple_re_bytes.go
# command-line-arguments
./grep_simple_re_bytes.go:18: inlining call to bufio.NewScanner
./grep_simple_re_bytes.go:20: inlining call to (*bufio.Scanner).Bytes
./grep_simple_re_bytes.go:16: fn escapes to heap
./grep_simple_re_bytes.go:16: err escapes to heap
./grep_simple_re_bytes.go:18: fp escapes to heap
./grep_simple_re_bytes.go:16: main ... argument does not escape
./grep_simple_re_bytes.go:18: main  literal does not escape
./grep_simple_re_bytes.go:24: main ([]byte)("\n") does not escape
:1: leaking param: io.p
:1: leaking param: .this


*I can see "./grep_simple_re.go:21: line escapes to heap" could be a 
problem in the first version.*

Here is the memory profiles of a run on 10million line 2.4 G file

$ go tool pprof ./grep_simple_re_mprofile 
/var/folders/bt/1mh2p2vx41lbnq3fz1n8qlxwgn/T/profile066323621/mem.pprof
Entering interactive mode (type "help" for commands)
(pprof) top10
86.37kB of 86.37kB total (  100%)
Dropped 4 nodes (cum <= 0.43kB)
Showing top 10 nodes out of 23 (cum >= 43.89kB)
  flat  flat%   sum%cum   cum%
   39.73kB 46.00% 46.00%39.73kB 46.00%  regexp.(*bitState).reset
   16.30kB 18.87% 64.87%16.30kB 18.87%  bufio.(*Scanner).Scan
   12.62kB 14.61% 79.48%12.62kB 14.61%  runtime.malg
9.04kB 10.47% 89.95%17.45kB 20.21%  runtime.allocm
4.52kB  5.23% 95.19% 4.52kB  5.23%  runtime.rawstringtmp
4.16kB  4.81%   100% 4.16kB  4.81%  regexp.progMachine
 0 0%   100%64.71kB 74.92%  main.main
 0 0%   100%43.89kB 50.82%  regexp.(*Regexp).MatchString
 0 0%   100%43.89kB 50.82%  regexp.(*Regexp).doExecute
 0 0%   100%43.89kB 50.82%  regexp.(*Regexp).doMatch
(pprof) quit
$ go tool pprof* -alloc_space* ./grep_simple_re_mprofile 
/var/folders/bt/1mh2p2vx41lbnq3fz1n8qlxwgn/T/profile066323621/mem.pprof
Entering interactive mode (type "help" for commands)
(pprof) top10
2.14GB of 2.14GB total (  100%)
Dropped 22 nodes (cum <= 0.01GB)
  flat  flat%   sum%cum   cum%
2.14GB   100%   100% 2.14GB   100%  runtime.rawstringtmp
 0 0%   100% 2.14GB   100%  main.main
 0 0%   100% 2.14GB   100%  runtime.goexit
 0 0%   100% 2.14GB   100%  runtime.main
 0 0%   100% 2.14GB   100%  runtime.slicebytetostring


*The only explanation for such a large change is if it grew the stack 2.4G 
in size for the first case. The SVG attached seems to show something like 
that. Instead if it was heap allocation, why didn't it show up in the first 
pprof (memory profile) output above? Does 'escape to heap' not imply it 
will be allocated in heap?Any call to re.Match or fmt.Println() escapes the 
string?*

 System details

```
go version go1.8 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/harry/code"
GORACE=""
GOROOT="/usr/local/go"

Re: [go-nuts] atomic bugs

[Ian Lance Taylor]

On Sat, Mar 18, 2017 at 12:03 PM, T L  wrote:
>
> At the end of sync/atomic package docs, it says
>
> On x86-32, the 64-bit functions use instructions unavailable before the
> Pentium MMX.
>
>
> On non-Linux ARM, the 64-bit functions use instructions unavailable before
> the ARMv6k core.
>
>
> So when running Go programs which call the 64-bit atomic functions on above
> mentioned machines, programs will crash?

Yes, I think you will that in those cases the program will die of a
`SIGILL` signal.


> If it is true, is it good idea to add a compiler option to convert the
> 64-bit function calls to mutex calls?

It's possible, but I don't think it's a good idea.  When was the last
time you saw an x86 that did not support the Pentium MMX instruction
set?


> And is it possible to do the conversions at run time?

That too is possible.


> And I read from somewhere which says Go authors are some regretted to expose
> the atomic functions,
>
> for these functions are intended to be used in standard packages internally.
>
> So is it a good idea to recommend gophers to use mutex over atomic and
> convert some mutex calls to atomic calls atomically by compiler?

Mutexes and atomic operations are different.  You can implement atomic
operations using mutexes, but you can't easily implement mutexes using
atomic operations.  A better way to think of it is that efficient
mutexes require atomic operations to work, but the mutex code is not
just the atomic instructions.  For example, there is no common used
atomic instruction that implements a mutex lock that suspends the
goroutine until the mutex is unlocked.

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] import/link problems with gccgo

[Ian Lance Taylor]

On Mon, Mar 20, 2017 at 4:25 PM, Ian Lance Taylor  wrote:
> On Mon, Mar 20, 2017 at 4:17 PM, Richard D'Addio  wrote:
>> With gccgo I get the following error the same builds fine with gc:
>>
>> //with native
>>
>> /home/rdaddio/mynewclient/clone_gobotics/gobotics/go/pkg/tool/linux_amd64/compile
>> -o $WORK/github.com/hashicorp/go-multierror.a -trimpath $WORK -p
>> github.com/hashicorp/go-multierror -complete -buildid
>> e777c32e05670dbca9940409bba89b18504d68f5 -importmap
>> github.com/hashicorp/errwrap=github.com/hashicorp/go-multierror/vendor/github.com/hashicorp/errwrap
>> -D
>> _/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/github.com/hashicorp/go-multierror
>> -I $WORK -I
>> /home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/pkg/linux_amd64 -pack
>> ./append.go ./flatten.go ./format.go ./multierror.go ./prefix.go
>>
>>
>> //with gccgo option
>>
>> /home/rdaddio/myGCC_run/myGCC_out/bin/gccgo -I $WORK -I
>> /home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/pkg/gccgo_linux_amd64
>> -c -g -m64 -fgo-pkgpath=github.com/hashicorp/go-multierror
>> -fgo-relative-import-path=_/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/github.com/hashicorp/go-multierror
>> -o $WORK/github.com/hashicorp/go-multierror/_obj/_go_.o ./append.go
>> ./flatten.go ./format.go ./multierror.go ./prefix.go
>>
>> mkdir -p $WORK/github.com/pkg/
>>
>> cd
>> /home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/github.com/pkg/errors
>>
>> /home/rdaddio/myGCC_run/myGCC_out/bin/gccgo -I $WORK -c -g -m64
>> -fgo-pkgpath=github.com/pkg/errors
>> -fgo-relative-import-path=_/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/github.com/pkg/errors
>> -o $WORK/github.com/pkg/errors/_obj/_go_.o ./errors.go ./stack.go
>>
>> # github.com/hashicorp/go-multierror
>>
>> lib/src/github.com/hashicorp/go-multierror/prefix.go:6:30: error: import
>> file 'github.com/hashicorp/errwrap' not found
>>
>>   "github.com/hashicorp/errwrap"
>>
>>   ^
>>
>> lib/src/github.com/hashicorp/go-multierror/prefix.go:30:20: error: reference
>> to undefined name 'errwrap'
>>
>> err.Errors[i] = errwrap.Wrapf(format, e)
>>
>> ^
>>
>> lib/src/github.com/hashicorp/go-multierror/prefix.go:35:10: error: reference
>> to undefined name 'errwrap'
>>
>>return errwrap.Wrapf(format, err)
>
>
> Thanks.  It looks like there is a bug with the implementation of
> vendor directories when using -compiler=gccgo.

In fact it's already been reported as https://golang.org/issue/15628.

Ian


>> On Monday, March 20, 2017 at 6:53:53 PM UTC-4, Ian Lance Taylor wrote:
>>>
>>> On Mon, Mar 20, 2017 at 3:40 PM, Richard D'Addio 
>>> wrote:
>>> > Sorry in advance if this is the wrong list for this.
>>> >
>>> >
>>> > I can build the gobot.io code below with the golang v1.8 and the
>>> > standard
>>> > compiler:
>>> >
>>> > go version go1.8 linux/amd64
>>> >
>>> > go build -work -x hello_blink.go
>>> >
>>> >
>>> > But when I try to build with the GCC option in the same scenario it
>>> > fails. I
>>> > am using GCC
>>> >
>>> > gccgo (GCC) 7.0.1 20170314 (experimental) which has go1.8 support & all
>>> > paths are correct:
>>> >
>>> > go build -work -x -compiler gccgo hello_blink.go
>>> >
>>> >
>>> > It can't seem to find paths that the gc code found and this leads to a
>>> > link
>>> > error. The problem is
>>> >
>>> > in a single file and if this file is commented out the code builds and
>>> > runs.
>>> > Since this code is likely unused
>>> >
>>> > it might be that the native compiler is detecting that automatically?
>>> >
>>> >
>>> > It didn't seem like any special options were needed to use the gccgo
>>> > compiler. I've used
>>> >
>>> > it elsewhere in a similar way (different go code of course) without
>>> > problems.
>>>
>>> You didn't tell us what actually happens.  How does it fail?
>>>
>>> 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.

-- 
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/link problems with gccgo

[Ian Lance Taylor]

On Mon, Mar 20, 2017 at 4:17 PM, Richard D'Addio  wrote:
> With gccgo I get the following error the same builds fine with gc:
>
> //with native
>
> /home/rdaddio/mynewclient/clone_gobotics/gobotics/go/pkg/tool/linux_amd64/compile
> -o $WORK/github.com/hashicorp/go-multierror.a -trimpath $WORK -p
> github.com/hashicorp/go-multierror -complete -buildid
> e777c32e05670dbca9940409bba89b18504d68f5 -importmap
> github.com/hashicorp/errwrap=github.com/hashicorp/go-multierror/vendor/github.com/hashicorp/errwrap
> -D
> _/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/github.com/hashicorp/go-multierror
> -I $WORK -I
> /home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/pkg/linux_amd64 -pack
> ./append.go ./flatten.go ./format.go ./multierror.go ./prefix.go
>
>
> //with gccgo option
>
> /home/rdaddio/myGCC_run/myGCC_out/bin/gccgo -I $WORK -I
> /home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/pkg/gccgo_linux_amd64
> -c -g -m64 -fgo-pkgpath=github.com/hashicorp/go-multierror
> -fgo-relative-import-path=_/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/github.com/hashicorp/go-multierror
> -o $WORK/github.com/hashicorp/go-multierror/_obj/_go_.o ./append.go
> ./flatten.go ./format.go ./multierror.go ./prefix.go
>
> mkdir -p $WORK/github.com/pkg/
>
> cd
> /home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/github.com/pkg/errors
>
> /home/rdaddio/myGCC_run/myGCC_out/bin/gccgo -I $WORK -c -g -m64
> -fgo-pkgpath=github.com/pkg/errors
> -fgo-relative-import-path=_/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/github.com/pkg/errors
> -o $WORK/github.com/pkg/errors/_obj/_go_.o ./errors.go ./stack.go
>
> # github.com/hashicorp/go-multierror
>
> lib/src/github.com/hashicorp/go-multierror/prefix.go:6:30: error: import
> file 'github.com/hashicorp/errwrap' not found
>
>   "github.com/hashicorp/errwrap"
>
>   ^
>
> lib/src/github.com/hashicorp/go-multierror/prefix.go:30:20: error: reference
> to undefined name 'errwrap'
>
> err.Errors[i] = errwrap.Wrapf(format, e)
>
> ^
>
> lib/src/github.com/hashicorp/go-multierror/prefix.go:35:10: error: reference
> to undefined name 'errwrap'
>
>return errwrap.Wrapf(format, err)


Thanks.  It looks like there is a bug with the implementation of
vendor directories when using -compiler=gccgo.

Ian



> On Monday, March 20, 2017 at 6:53:53 PM UTC-4, Ian Lance Taylor wrote:
>>
>> On Mon, Mar 20, 2017 at 3:40 PM, Richard D'Addio 
>> wrote:
>> > Sorry in advance if this is the wrong list for this.
>> >
>> >
>> > I can build the gobot.io code below with the golang v1.8 and the
>> > standard
>> > compiler:
>> >
>> > go version go1.8 linux/amd64
>> >
>> > go build -work -x hello_blink.go
>> >
>> >
>> > But when I try to build with the GCC option in the same scenario it
>> > fails. I
>> > am using GCC
>> >
>> > gccgo (GCC) 7.0.1 20170314 (experimental) which has go1.8 support & all
>> > paths are correct:
>> >
>> > go build -work -x -compiler gccgo hello_blink.go
>> >
>> >
>> > It can't seem to find paths that the gc code found and this leads to a
>> > link
>> > error. The problem is
>> >
>> > in a single file and if this file is commented out the code builds and
>> > runs.
>> > Since this code is likely unused
>> >
>> > it might be that the native compiler is detecting that automatically?
>> >
>> >
>> > It didn't seem like any special options were needed to use the gccgo
>> > compiler. I've used
>> >
>> > it elsewhere in a similar way (different go code of course) without
>> > problems.
>>
>> You didn't tell us what actually happens.  How does it fail?
>>
>> 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.

-- 
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 were tabs chosen for indentation?

[Dan Kortschak]

On Mon, 2017-03-20 at 09:45 +0100, 'Axel Wagner' via golang-nuts wrote:
> The "philosophy of gofmt" was to end arguments about how go code
> should be formatted.
> Which gives this thread a special form of irony :)


People will always adjust their behaviour to minimise the delta on
their dissatisfaction with the world and their personal unhappiness set
point. Sometimes this means complaining about things that don't really
matter.

-- 
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/link problems with gccgo

[Richard D'Addio]

With gccgo I get the following error the same builds fine with gc:

*//with native*

/home/rdaddio/mynewclient/clone_gobotics/gobotics/go/pkg/tool/linux_amd64/compile
 
-o $WORK/github.com/hashicorp/go-multierror.a -trimpath $WORK -p 
github.com/hashicorp/go-multierror -complete -buildid 
e777c32e05670dbca9940409bba89b18504d68f5 -importmap 
github.com/hashicorp/errwrap=github.com/hashicorp/go-multierror/vendor/github.com/hashicorp/errwrap
 
-D 
_/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/github.com/hashicorp/go-multierror
 
-I $WORK -I 
/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/pkg/linux_amd64 -pack 
./append.go ./flatten.go ./format.go ./multierror.go ./prefix.go


*//with gccgo option*

/home/rdaddio/myGCC_run/myGCC_out/bin/gccgo -I $WORK -I 
/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/pkg/gccgo_linux_amd64 
-c -g -m64 -fgo-pkgpath=github.com/hashicorp/go-multierror 
-fgo-relative-import-path=_/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/github.com/hashicorp/go-multierror
 
-o $WORK/github.com/hashicorp/go-multierror/_obj/_go_.o ./append.go 
./flatten.go ./format.go ./multierror.go ./prefix.go

mkdir -p $WORK/github.com/pkg/

cd 
/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/github.com/pkg/errors

/home/rdaddio/myGCC_run/myGCC_out/bin/gccgo -I $WORK -c -g -m64 
-fgo-pkgpath=github.com/pkg/errors 
-fgo-relative-import-path=_/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/github.com/pkg/errors
 
-o $WORK/github.com/pkg/errors/_obj/_go_.o ./errors.go ./stack.go

# github.com/hashicorp/go-multierror

lib/src/github.com/hashicorp/go-multierror/prefix.go:6:30: error: import 
file 'github.com/hashicorp/errwrap' not found

  "github.com/hashicorp/errwrap"

  ^

lib/src/github.com/hashicorp/go-multierror/prefix.go:30:20: error: 
reference to undefined name 'errwrap'

err.Errors[i] = errwrap.Wrapf(format, e)

^

lib/src/github.com/hashicorp/go-multierror/prefix.go:35:10: error: 
reference to undefined name 'errwrap'

   return errwrap.Wrapf(format, err)




On Monday, March 20, 2017 at 6:53:53 PM UTC-4, Ian Lance Taylor wrote:
>
> On Mon, Mar 20, 2017 at 3:40 PM, Richard D'Addio  > wrote: 
> > Sorry in advance if this is the wrong list for this. 
> > 
> > 
> > I can build the gobot.io code below with the golang v1.8 and the 
> standard 
> > compiler: 
> > 
> > go version go1.8 linux/amd64 
> > 
> > go build -work -x hello_blink.go 
> > 
> > 
> > But when I try to build with the GCC option in the same scenario it 
> fails. I 
> > am using GCC 
> > 
> > gccgo (GCC) 7.0.1 20170314 (experimental) which has go1.8 support & all 
> > paths are correct: 
> > 
> > go build -work -x -compiler gccgo hello_blink.go 
> > 
> > 
> > It can't seem to find paths that the gc code found and this leads to a 
> link 
> > error. The problem is 
> > 
> > in a single file and if this file is commented out the code builds and 
> runs. 
> > Since this code is likely unused 
> > 
> > it might be that the native compiler is detecting that automatically? 
> > 
> > 
> > It didn't seem like any special options were needed to use the gccgo 
> > compiler. I've used 
> > 
> > it elsewhere in a similar way (different go code of course) without 
> > problems. 
>
> You didn't tell us what actually happens.  How does it fail? 
>
> 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] Only build go binary from source

[Ian Lance Taylor]

On Sun, Mar 19, 2017 at 3:29 PM,   wrote:
>
> I am tinkering with some runtime code and I would like to build only the go
> binary to the test it on a small program I wrote. I don't see any script in
> the source that would allow that, all of these also try to compile the
> standard library. I would like to avoid that, because it's easier for me to
> test my changes first on smaller snippet of code. How can I build only the
> main binary (and where it is going to be available)?

I don't know if I understand you, but I think the answer to your
question is to avoid using the go tool.  Instead of using `go build
x.go` use `go tool compile x.go && go tool link -o x x.o`.

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] Inspecting a function for its arguments with reflection

[Tyler Compton]

Also, if there already exists a library that does this kind of magic for
REST APIs, I'd love to hear about it.

On Mon, Mar 20, 2017 at 4:01 PM Tyler Compton  wrote:

> I'm trying to create an HTTP request router library that automatically
> decodes parameters in the request URL and passes them as arguments to the
> handler function. It would theoretically make something like this possible:
>
> myRouter.HandleFunc("/getPuppies/{id}", func(w http.ResponseWriter, r *
> http.Request, id string) {
> // Handle the request
> });
>
> I am aware that you can't get the name of a function's arguments. That's
> okay with me, I can just pass the params in the order they appear. However,
> I do need to be able to check how many arguments a function has and what
> the types of those arguments are, so I can type assert the parameters and
> give sane error messages when the user makes a mistake.
>
> Before you point out that this is a bad idea and that reflection is never
> clear, I am fully aware! I'm doing this to learn about reflection in Go and
> to see if Go can support a workflow something like Java's JAX-RS.
>
> --
> 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] How to control the symbol visibility of shared lib built from Go

[Ian Lance Taylor]

On Mon, Mar 20, 2017 at 4:51 AM, Song Liu  wrote:
>
> I am going to write a shared library using the Go, you know that the Go
> runtime and used libraries are compiled into the library together.
>
> But it seems that all the symbols from this library is "DEFAULT", is there a
> way to use the "HIDDEN" symbol visibility by default, but "DEFAULT" only for
> the API exposed by this library.
>
> This is could be done in c/c++ via. the "__attribute__(visibility(default))"
> and "-fvisiblity=hidden", what will do in CGO ?

No, this is not currently available in Go.

It's not clear to me that anybody would actually want this, as having
multiple copies of a hidden symbol would then to break things.

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] Inspecting a function for its arguments with reflection

[Tyler Compton]

I'm trying to create an HTTP request router library that automatically 
decodes parameters in the request URL and passes them as arguments to the 
handler function. It would theoretically make something like this possible:

myRouter.HandleFunc("/getPuppies/{id}", func(w http.ResponseWriter, r *http.
Request, id string) {
// Handle the request
});

I am aware that you can't get the name of a function's arguments. That's 
okay with me, I can just pass the params in the order they appear. However, 
I do need to be able to check how many arguments a function has and what 
the types of those arguments are, so I can type assert the parameters and 
give sane error messages when the user makes a mistake.

Before you point out that this is a bad idea and that reflection is never 
clear, I am fully aware! I'm doing this to learn about reflection in Go and 
to see if Go can support a workflow something like Java's JAX-RS.

-- 
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/link problems with gccgo

[Richard D'Addio]

 

Sorry in advance if this is the wrong list for this.


I can build the gobot.io code below with the golang v1.8 and the standard 
compiler:

go version go1.8 linux/amd64

go build -work -x hello_blink.go


But when I try to build with the GCC option in the same scenario it fails. 
I am using GCC

gccgo (GCC) 7.0.1 20170314 (experimental) which has go1.8 support & all 
paths are correct:

go build -work -x -compiler gccgo hello_blink.go


It can't seem to find paths that the gc code found and this leads to a link 
error. The problem is

in a single file and if this file is commented out the code builds and 
runs. Since this code is likely unused

it might be that the native compiler is detecting that automatically?


It didn't seem like any special options were needed to use the gccgo 
compiler. I've used

it elsewhere in a similar way (different go code of course) without 
problems.


Any ideas? Thanks.


//hello_blink

package main


import (

"time"


"gobot.io/x/gobot"

"gobot.io/x/gobot/drivers/gpio"

"gobot.io/x/gobot/platforms/firmata"

)


func main() {

firmataAdaptor := firmata.NewAdaptor("/dev/ttyACM0")

led := gpio.NewLedDriver(firmataAdaptor, "13")


work := func() {

gobot.Every(1*time.Second, func() {

led.Toggle()

})

}


robot := gobot.NewRobot("bot",

[]gobot.Connection{firmataAdaptor},

[]gobot.Device{led},

work,

)


robot.Start()

}


-- 
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] [ANN] go-resty v0.11 release - simple HTTP and REST client library

[jeeva . tkm]

Stable Version : gopkg.in/resty.v0
Edge Version   : https://github.com/go-resty/resty
godoc  : https://godoc.org/github.com/go-resty/resty

*This release brings following:*

*Releases Notes:* https://github.com/go-resty/resty/releases/latest

*Feature:*

   - Request based on SRV record support (instead of Host URL)

*Enhancement(s):*

   - Added `IsProxySet()` method on `resty.Client`
   - Performance improvement, no more mutex and `resty` is truely parallel
   - Using `http.Client.SetTimeout` for go1.3 and above
   - Added nil check for `RawResponse`, so `RetryConditionFunc` 
   implementation at ease

*Bug:*

   - OnBeforeRequest does not change Request.RawRequest attributes

*Breaking Change:*

   - Individual Request level proxy support have been removed from `resty`
   

I appreciate your support & feedback!

Regards,
Jeeva

-- 
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] Extracting ssh public key from private key file using go

[even . simon]

I'm using this method to extract and get the public key string from an 
original ssh private key. They key ends up to be broken/badly formatted. 
I've checked it against the key generated by ssh-keygen and the first few 
chars are different. Anyone has any ideas?

func ExtractPublicKey(der []byte) (*string, error) {
   var privateKey crypto.PrivateKey
   var publicKey crypto.PublicKey
   var ok bool = true
   var err error

   privateKey, err = ssh.ParseRawPrivateKey([]byte(der))

   if err != nil {
  return nil, err
   }
   switch privateKey.(type) {
   case *rsa.PrivateKey:
  fmt.Println("*rsa.PrivateKey")
  key := privateKey.(*rsa.PrivateKey)
  publicKey = key.PublicKey
   case *ecdsa.PrivateKey:
  fmt.Println("*ecdsa.PrivateKey")
  key := privateKey.(*ecdsa.PrivateKey)
  publicKey = key.Public()
   case *dsa.PrivateKey:
  fmt.Println("*dsa.PrivateKey")
  key := privateKey.(*dsa.PrivateKey)
  publicKey = key.PublicKey
   case *ed25519.PrivateKey:
  fmt.Println("*ed25519.PrivateKey")
  key := privateKey.(*ed25519.PrivateKey)
  publicKey = key.Public()
   default:
  return nil, errors.New("Failed to defined key type")
   }
   if !ok {
  return nil, fmt.Errorf("Failed to convert key to %s", 
"rsa.PrivateKey")
   }
   fmt.Println(string(ssh.Marshal(publicKey)))

   str := base64.StdEncoding.EncodeToString(ssh.Marshal(publicKey))
   return , nil
}



-- 
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] Best way to save users input data that could be used later?

[Paulius Daubaris]

Hello, I am writing this application, where I can store some reminders for 
myself in CLI to not forget something important.

My question is how can I save my input data or lets say what's the best way 
to do so? I've tried JSON, but it didnt work out, primarily because I cant 
really figure it out. Anyhow if JSON is the way to go, I've been stuck and 
it got me really frustrated.

Example:

The function which creates new reminder:

func newReminder() {
checkFile() //Simple check if file is not in the directory it creates 
one

var text string
date := time.Now()
dateString := date.String()
file, err := os.OpenFile("rem.json", os.O_RDWR|os.O_APPEND, os.ModePerm)

if err != nil {
log.Fatal(err)
}

fmt.Print("Description: ")

scanner := bufio.NewScanner(os.Stdin)
if ok := scanner.Scan(); ok {
text = scanner.Text()
}

reminder := {dateString[:19], text}
newReminder, _ := json.Marshal()

file.Write(newReminder)
file.Close()
}

Here everything is working fine. I execute it with ./main -n, write new 
reminder, display it and it goes well. Although when I add another reminder 
and try to display it i get an error: invalid character '{' after top-level 
value
Its because when I cat out my json file it looks like this :

{"Date":"2017-03-20 10:46:48","Description":"new"}{"Date":"2017-03-20 
10:46:51","Description":"new .go"}

So basically it has no root node. So again, is there a way to wrap it up? If 
the code is confusing here's the whole. https://play.golang.org/p/d0mlZw3ZH-

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] [ANN] go-resty v0.11 release - simple HTTP and REST client library

[Jeevanandam M.]

Stable Version : gopkg.in/resty.v0
Edge Version   : https://github.com/go-resty/resty
godoc  : https://godoc.org/github.com/go-resty/resty

*This release brings following:*

*Releases Notes:* https://github.com/go-resty/resty/releases/latest

*Feature:*

   - Request based on SRV record support (instead of Host URL)

*Enhancement(s):*

   - Added `IsProxySet()` method on `resty.Client`
   - Performance improvement, no more mutex and `resty` is truely parallel
   - Using `http.Client.SetTimeout` for go1.3 and above
   - Added nil check for `RawResponse`, so `RetryConditionFunc` 
   implementation at ease

*Bug:*

   - OnBeforeRequest does not change Request.RawRequest attributes

*Breaking Change:*

   - Individual Request level proxy support have been removed from `resty`
   

I appreciate your support & feedback!

Regards,
Jeeva

-- 
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: a some naive question, but I can't find the answer from Go spec. Is it possible compiler adds paddings between array elements sometimes?

[peterGo]

T L,

For example: https://play.golang.org/p/BSwB8jQwBY
Peter

On Monday, March 20, 2017 at 1:24:46 PM UTC-4, peterGo wrote:
>
> s/strcts/structs/
>
> On Monday, March 20, 2017 at 1:24:06 PM UTC-4, peterGo wrote:
>>
>> TL,
>>
>> https://golang.org/ref/spec#Size_and_alignment_guarantees
>>
>> For eample, some strcts.
>>
>> Peter
>>
>> On Monday, March 20, 2017 at 11:23:02 AM UTC-4, T L wrote:
>>>
>>> Or if the first element in an array is 64bit aligned and the size of 
>>> array elements is 8N bytes,
>>> is it for sure that all elements in the array are 64bit aligned?
>>>
>>

-- 
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: a some naive question, but I can't find the answer from Go spec. Is it possible compiler adds paddings between array elements sometimes?

[peterGo]

s/strcts/structs/

On Monday, March 20, 2017 at 1:24:06 PM UTC-4, peterGo wrote:
>
> TL,
>
> https://golang.org/ref/spec#Size_and_alignment_guarantees
>
> For eample, some strcts.
>
> Peter
>
> On Monday, March 20, 2017 at 11:23:02 AM UTC-4, T L wrote:
>>
>> Or if the first element in an array is 64bit aligned and the size of 
>> array elements is 8N bytes,
>> is it for sure that all elements in the array are 64bit aligned?
>>
>

-- 
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: a some naive question, but I can't find the answer from Go spec. Is it possible compiler adds paddings between array elements sometimes?

[peterGo]

TL,

https://golang.org/ref/spec#Size_and_alignment_guarantees

For eample, some strcts.

Peter

On Monday, March 20, 2017 at 11:23:02 AM UTC-4, T L wrote:
>
> Or if the first element in an array is 64bit aligned and the size of array 
> elements is 8N bytes,
> is it for sure that all elements in the array are 64bit aligned?
>

-- 
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: togo: tool for converting files to .go

[Zellyn]

https://github.com/jteeuwen/go-bindata is the one I see most often. There 
are several alternatives listed in the README 
at https://github.com/shurcooL/vfsgen

On Monday, March 20, 2017 at 12:02:47 PM UTC-4, Francesco Lazzarino wrote:
>
> Hi,
>
> I made a handy tool that converts a file in a pkgs to a src file with a 
> []byte var. Then you can compile arbitrary files into a pkg. I found it 
> handy for use via go generate.
>
> https://github.com/flazz/togo
>
> If this is a solved problem (or a bad approach) let me know, I'll amend 
> the README with alternatives.
>
> Hope it helps anyone
>
> -Franco
>

-- 
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] togo: tool for converting files to .go

[Francesco Lazzarino]

Hi,

I made a handy tool that converts a file in a pkgs to a src file with a 
[]byte var. Then you can compile arbitrary files into a pkg. I found it 
handy for use via go generate.

https://github.com/flazz/togo

If this is a solved problem (or a bad approach) let me know, I'll amend the 
README with alternatives.

Hope it helps anyone

-Franco

-- 
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] a some naive question, but I can't find the answer from Go spec. Is it possible compiler adds paddings between array elements sometimes?

[T L]

Or if the first element in an array is 64bit aligned and the size of array 
elements is 8N bytes,
is it for sure that all elements in the array are 64bit aligned?

-- 
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] Mocking Practice

[Jamie Stackhouse]

I have an implementation of a storage interface for 
github.com/RangelReale/osin that I would like to be able to test each 
function in isolation. One of the aspects of the interface is that certain 
functions must return with data loaded that other functions are responsible 
for returning in the interface, which makes you have struct methods that 
call other struct methods.

So, you end up with dependency chains like LoadAccess must return Client 
information, so LoadAccess then depends on GetClient. To test each function 
in isolation, I wanted to be able to mock the call to GetClient, so I wrote 
out a little test mock like I have 
before: https://play.golang.org/p/P2-BDZDW9i

The problem with the test mock in this case is how it must both call the 
real implementation, as well as provide a mock. The call makes it so the 
later call to GetData doesn't go through the indirection layer of the 
storageMock object, it directly calls the underlying object, and therefore 
skips the indirection.

I asked golang-slack, and the response I got was to essentially have the 
implementation just be done like the mock, so your unit test could simply 
change the implementation and be able to pass functions similar to how I 
implemented the storageMock. I was wondering if anyone had another option, 
or is the best way to make this type of code testable to make it always 
have the indirection layer from struct method to struct field which is a 
func literal?

Thank you all.

-- 
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 return a Go struct to C

[Steven Hartland]

The following may help:
http://feisky.xyz/2016/04/19/cgo-in-go-1-6/

On 20/03/2017 13:25, Song Liu wrote:

Hi,

I have a shared lib as bellow:

|
/*
#include
structMedia{
char*Name;
char*Path;
uint64_tSize;
};
*/
import"C"
//exportGetMediaFromDB
funcGetMediaFromDB(filename*C.char)*C.struct_Media{
c_struct_media:=_Media{}
returnc_struct_media
}
|

Which is called in another program written by C, but when it's running 
it report error:


|
panic:runtime error:cgo result has Gopointer
|

Could you help with the correct way to return a struct from Go ?

Many thanks.

Thanks,
Song
--
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] How to return a Go struct to C

[Song Liu]

Hi,

I have a shared lib as bellow:

/*

#include 


struct Media {

char*Name;

char*Path;

uint64_t Size;

};

*/

import "C"


//export GetMediaFromDB


func GetMediaFromDB(filename *C.char) *C.struct_Media {


c_struct_media := _Media{}


return c_struct_media

}


Which is called in another program written by C, but when it's running it 
report error:

panic: runtime error: cgo result has Go pointer

Could you help with the correct way to return a struct from Go ?

Many thanks.

Thanks,
Song

-- 
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 control the symbol visibility of shared lib built from Go

[Song Liu]

Hi,

I am going to write a shared library using the Go, you know that the Go 
runtime and used libraries are compiled into the library together.

But it seems that all the symbols from this library is "DEFAULT", is there 
a way to use the "HIDDEN" symbol visibility by default, but "DEFAULT" only 
for the API exposed by this library.

This is could be done in c/c++ via. the 
"__attribute__(visibility(default))" and "-fvisiblity=hidden", what will do 
in CGO ?

Thanks,
Song

-- 
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 accept any function with one return value as a parameter

[Konstantin Khomoutov]

On Sun, 19 Mar 2017 13:51:05 -0700 (PDT)
aktungmak  wrote:

> I am trying to write a function that initializes a generic
> collection. For adding new items to the collection, the user
> specifies a constructor which takes one argument and returns a
> pointer to the struct that will be inserted in the collection, and
> also sets fields to initial values. For example:
> 
> func Constructor(id int) *NewItemX ...
> func Constructor(id int) *NewItemY ...
> func Constructor(id int) *NewItemZ ...
> 
> In the constructor for the collection, I want to accept any function
> which has this general form, although the return type will be
> different for each struct. At first, I thought this might work:
> 
> func NewCollection(itemCtr func(int) interface{}) *Collection ...
> 
> but of course, trying to pass Constructor fails during compilation
> since the types *NewItemX and interface{} do not match:
> 
> .\Collection_test.go:xx: cannot use NewItemX (type func(int)
> *NewItemX) as type func(int) interface {} in argument to NewCollection

I think that's because of [1].

> I could just do this:
> 
> func NewCollection(itemCtr interface{}) *Collection
> 
> but then I would have to do some runtime checks using reflect to make
> sure that it is a func etc and I lose compile-time checking of types.
> 
> How can I express this best in go?

I'd say that your constructor function's type should be defined to
return an interface{} but the actual function should return values of
concrete types -- *NewItemX, *NewItemY etc.

Something like this ([2] on playground):
--8<--
package main

type ItemCtor func() interface{}

type Foo struct{}

type FooCollection []*Foo

func ConctructFooCollection(ctor ItemCtor) FooCollection {
out := make(FooCollection, 10)
for i := range out {
out[i] = ctor().(*Foo)
}
return out
}

func userProvidedFooPtrCtor() interface{} {
return {}
}

func main() {
_ = ConctructFooCollection(userProvidedFooPtrCtor)
}
--8<--

This supposes your collection actually knows the types of its elements.
If it doesn't, we need more context to know, probably.

1. https://golang.org/doc/faq#covariant_types
2. https://play.golang.org/p/l-K5knQCd5

-- 
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 were tabs chosen for indentation?

['Axel Wagner' via golang-nuts]

The "philosophy of gofmt" was to end arguments about how go code should be
formatted.
Which gives this thread a special form of irony :)

On Mon, Mar 20, 2017 at 1:59 AM, Wojciech S. Czarnecki 
wrote:

>
> > > On Sun, 19 Mar 2017, at 09:35 PM, Rob Pike wrote:
> > > everyone will see code indented as wide (or not) as they prefer.
>
> > Ian Davis  wrote:
> > It seems to me that this explanation is at odds with the philosophy of
> > gofmt which is that there is a single way to lay out code.
>
> > The benefits of that are obvious but using tabs erodes it somewhat when
> > you read code on another computer.
>
> It is that person who prefers particular tab width who sees code on
> 'another'
> computer. Gofmt makes code 'style' uniform for readability.
> Forced tabs make code familiar with indentation one is
> accustomed to.
>
>
> > I always felt the reason for using tabs was to enable support for non-
> > monospaced fonts and multi-width characters. A tab stop in the
> > traditional sense is a linear position, not a number of characters.
>
> --
> Wojciech S. Czarnecki
>^oo^ OHIR-RIPE
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] plugins (Go 1.8) and packages

[Basile Starynkevitch]

Hello all,

Here are some thoughts and questions about plugins in Go 1.8 (which I use 
on Linux/x86-64).

*Plugins in other languages*

In C and C++ code (on Linux), plugins are practically not exactly the same 
as e.g. shared objects (a good reference would be Drepper's *How To Write 
Shared Libraries*  paper). In 
practice, a plugin is a (dlopen-ed) shared object *with references to 
symbols in the main program*. For example, a GCC plugin 
 (this is an example 
that both Ian Taylor & me know well) will call functions from GCC itself 
(such as register_callback or many others, e.g. gimple_block etc etc...). 
Likewise, a GEDIT plugin  
(for example the wordcompletion 

 
one) will call GEDIT or GTK functions like gedit_debug or 
gtk_text_view_get_buffer etc...). Notice that to make that possible the 
main program (cc1plus for GCC
or gedit) has to be linked with the -rdynamic flag (to make the symbols of 
the main program visible from the plugin). Even if that is in theory 
principle, it is 

uncommon to dlopen a shared object which is not a plugin, designed and coded to 
call *symbols* from the *main program* (a program might in theory dlopen some 
plain shared library  like /usr/lib/x86_64-linux-gnu/libgdbm.so.3 but in 
practice this is never done; program loading plugins are dlopen-ing some 
shared object -the plugin- *specifically designed* for them, and *calling 
functions* from the main program, and the main program uses dlsym to find some 
specific 
symbols such as plugin_init for GCC obeying some signature convention). I 
deliberately ignore plugins loading other plugins (but I know about RTLD_GLOBAL 
flag to dlopen )
and I know about constructor function attributes 
 in plugins.

In JAVA, there are class loaders 
 with a sophisticated protocol 
for loading them.

In Ocaml, you have the dynlink 
 library. The 
Dynlink.loadfile function 
 is similar to 
dlopen (and will run the plugin initialization code).
There is no equivalent of dlsym: the plugin is supposed to e.g.  register 
function values at initialization time, perhaps by passing them to 
some function of the main program. Of course the plugin can call functions from 
the main program.

*Plugins and packages in Go*

The *package* concept is a core concept of Go since every source file belongs 
to some package (with main being a special case) and often imports several 
other ones.
Practically speaking, a Go plugin is likely to call functions from some package 
defined by the main program and having itself (the plugin) some packages. So the
 tiny example in plugin documentation  is a 
bit too naive (even if it is calling fmt.Printf). A *realistic example* would 
be a program having not only some main function 
in its main package, but also defining some purple package having some Foo 
public function called as purple.Foo from main and having a Bar public function
(with purple.Bar called from the plugin). The plugin would have not only some 
public F function in its main package (which should call purple.Bar from the 
main 
plugin-loading program) but also some plugin specific yellow package with a 
public Y function called (as yellow.Y) from F. I hope that such a realistic 
example will be 
given in the documentation of future Go 1.9.


Unfortunately, I know no public mechanism to say, within the source code of 
a plugin, that some imported package is (and has to be) provided by the 
main loading program.
I would suggest to re-use and extend the import comment 
 convention (with the 
path "*" being a notation to say *import that package from the main loading 
program*). For example, our plugin.go source code might have import 
"purple" // import "*" on a single line, and then the purple package would 
be externally linked (not incorporated in the plugin; exactly like in some 
GCC plugin calling gimple_block does not add all the existing GIMPLE 
processing code into the plugin).

Currently, a plugin which uses some package (even a standard one like fmt; 
but I am thinking of a program-supplied one like purple)  is linking it 
*twice* (once in the main program, and once in the plugin). This is 
*inefficient* (compile time of plugins -even a tiny one- is huge, and their 
shared object size is much too big) and *error prone* (it is not defined 
what happens if the version of that package is different, and there might 
be -in