[go-nuts] How to separate Unit and Integration tests

[tanya - cube]

How to separate Unit and Integration tests 


-- 
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: the case for returning interface vs struct

[Henrik Johansson]

This comes down to encapsulation I guess. You may want to hide some
internals and perhaps not other.
Simple data types are probably fine but say that you have an interface
Store then you can have redisStore or cassandraStore both implementing the
same interface and the rest of your program just operate on the interface
Store. Easy to change and (knock, knock) evolve.

tors 2 mars 2017 kl 07:50 skrev Henry :

> If you simply return unexported data types, there is no way your data
> users can understand what your data type does since godoc does not document
> unexported types.
>
>
> On Thursday, March 2, 2017 at 1:27:42 PM UTC+7, Tamás Gulácsi wrote:
>
> Accept interface (the smallest possible) but return concrete type -
> possibly a pointer.
> If you don't want people to mess with your data type directly, unexport
> (lowercase the first rune in the name) your data type.
>
> --
> 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: why the second memory allocation is blocked?

[Dave Cheney]

Yup. A syscall causes the scheduler to create a new thread that replaces the 
one blocking on the syscall. 

-- 
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: the case for returning interface vs struct

[Henry]

If you simply return unexported data types, there is no way your data 
users can understand what your data type does since godoc does not document 
unexported types.  

On Thursday, March 2, 2017 at 1:27:42 PM UTC+7, Tamás Gulácsi wrote:
>
> Accept interface (the smallest possible) but return concrete type - 
> possibly a pointer.
> If you don't want people to mess with your data type directly, unexport 
> (lowercase the first rune in the name) your data type.

-- 
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] the case for returning interface vs struct

[Tamás Gulácsi]

Accept interface (the smallest possible) but return concrete type - possibly a 
pointer.
If you don't want people to mess with your data type directly, unexport 
(lowercase the first rune in the name) your data type.

-- 
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: why the second memory allocation is blocked?

[Kai Zhang]

Thanks, got it. The GC is waiting on the busy goroutine. When I call 
syscall in the busy loop goroutine, the second allocation in main goroutine 
is continued.

On Thursday, March 2, 2017 at 1:47:42 PM UTC+8, Dave Cheney wrote:
>
> Your spinning goroutine is block the garbage collector which needs to 
> stop, temporarily, all the running goroutines to make love objects. 

-- 
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: why the second memory allocation is blocked?

[Dave Cheney]

Your spinning goroutine is block the garbage collector which needs to stop, 
temporarily, all the running goroutines to make love objects. 

-- 
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: why the second memory allocation is blocked?

[Kai Zhang]

But i have 4 os threads to schedule the goroutines, there are spare CPU to 
run the main goroutine.

On Thursday, March 2, 2017 at 12:50:35 PM UTC+8, Henry wrote:
>
> Hi,
>
> The processing power for your second allocation is consumed by your 
> goroutine. There is an endless loop in your goroutine. Eventually, when 
> there is enough juice, your second allocation will be called.
>
> On Thursday, March 2, 2017 at 11:07:08 AM UTC+7, Kai Zhang wrote:
>
>> package main
>>
>> import (
>> "fmt"
>> _ "net/http/pprof"
>> "runtime"
>> "sync"
>> "time"
>> )
>>
>> const size = 100
>>
>> func alloc(n int) {
>> fmt.Printf("alloc %v, before alloc\n", n)
>> _ = make([]int, size, size)
>> fmt.Printf("alloc %v, after alloc\n", n)
>> }
>>
>> var wg sync.WaitGroup
>>
>> func main() {
>> cpunum := runtime.NumCPU()
>> runtime.GOMAXPROCS(cpunum)
>>
>> alloc(1)
>>
>> wg.Add(1)
>> go func() {
>> fmt.Printf("in go func\n")
>> defer wg.Done()
>> for true {
>> }
>> }()
>> time.Sleep(time.Second)
>> alloc(2)
>> wg.Wait()
>> }
>>
>> run this code on my linux machine, which has 4 CPU. 
>> Only output the following message, then hanging:
>> alloc 1, before alloc
>> alloc 1, after alloc
>> in go func
>> alloc 2, before alloc
>>
>>
>>
>>

-- 
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: why the second memory allocation is blocked?

[Henry]

Hi,

The processing power for your second allocation is consumed by your 
goroutine. There is an endless loop in your goroutine. Eventually, when 
there is enough juice, your second allocation will be called.

On Thursday, March 2, 2017 at 11:07:08 AM UTC+7, Kai Zhang wrote:

> package main
>
> import (
> "fmt"
> _ "net/http/pprof"
> "runtime"
> "sync"
> "time"
> )
>
> const size = 100
>
> func alloc(n int) {
> fmt.Printf("alloc %v, before alloc\n", n)
> _ = make([]int, size, size)
> fmt.Printf("alloc %v, after alloc\n", n)
> }
>
> var wg sync.WaitGroup
>
> func main() {
> cpunum := runtime.NumCPU()
> runtime.GOMAXPROCS(cpunum)
>
> alloc(1)
>
> wg.Add(1)
> go func() {
> fmt.Printf("in go func\n")
> defer wg.Done()
> for true {
> }
> }()
> time.Sleep(time.Second)
> alloc(2)
> wg.Wait()
> }
>
> run this code on my linux machine, which has 4 CPU. 
> Only output the following message, then hanging:
> alloc 1, before alloc
> alloc 1, after alloc
> in go func
> alloc 2, before alloc
>
>
>
>

-- 
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: why the second memory allocation is blocked?

[Kai Zhang]

go version go1.7.5 linux/amd64

-- 
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 the second memory allocation is blocked?

[Kai Zhang]

package main

import (
"fmt"
_ "net/http/pprof"
"runtime"
"sync"
"time"
)

const size = 100

func alloc(n int) {
fmt.Printf("alloc %v, before alloc\n", n)
_ = make([]int, size, size)
fmt.Printf("alloc %v, after alloc\n", n)
}

var wg sync.WaitGroup

func main() {
cpunum := runtime.NumCPU()
runtime.GOMAXPROCS(cpunum)

alloc(1)

wg.Add(1)
go func() {
fmt.Printf("in go func\n")
defer wg.Done()
for true {
}
}()
time.Sleep(time.Second)
alloc(2)
wg.Wait()
}

run this code on my linux machine, which has 4 CPU. 
Only output the following message, then hanging:
alloc 1, before alloc
alloc 1, after alloc
in go func
alloc 2, before alloc



-- 
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] the case for returning interface vs struct

[Henry]

Hi, 

I am trying to come up with a general guideline about returning struct vs 
returning interface. I have used both approaches. Despite the common wisdom 
is to return struct, I believe that returning interface is generally 
superior to returning struct. Here are my arguments for returning interface:

First, you may not want your data type to be copied by value. The data type 
may contain mutexes, references to other data types, etc. If you 
are returning struct, you may need to put comments in your code to prevent 
people from copying your data type by value. Note that this isn't ideal 
because an implementation is supposed to be a black box and the user should 
not need to know whether there is a mutex, etc. inside the struct.  

//DO NOT COPY. I MEAN IT!
type VolatileDataType struct{
   mtx sync.RWMutex
   data  map[string]OtherData
   //etc..
}

With the above comment, while people may remember not to do this:
myCopy := myVolatileDataType //myVolatileDataType is of type 
VolatileDataType


It is harder to prevent people from doing these:
func DoWork(data VolatileDataType){
   //...
}
//or this 
func DoWork() VolatileDataType{
   //...
}
//or this
myChannel := make (chan VolatileDataType)


If you are returning interface, you avoid all these complications in a 
somewhat simpler way:
type VolatileDataType interface{
   Clone() VolatileDataType
   //...
}

type volatileImpl struct{
   mtx  sync.RWMutex 
   data map[string]OtherData
   //etc...
}

func NewVolatileDataType() VolatileDataType{
   return {
  //etc...
   }
}


By returning interface, people can do all the followings without any 
problem. You are actually passing around references to the actual object, 
and you will have to explicitly call its copy method if you need a copy.
myPtr := myVolatileDataType //in the case of passing the actual data type 
around 
//or
myCopy := myVolatileDataType.Clone() //if the data type supports copying

func DoWork(data VolatileDataType){
   //...
}

func DoWork() VolatileDataType{
   //...
}

myChannel := make (chan VolatileDataType)

In the case where your data type can be safely passed around by value, it 
doesn't matter whether you return interface or struct. So there isn't 
a problem in returning interface.

Second, returning interface removes the need for dereferencing your data 
type. It results in a cleaner syntax. It also allows better equality 
comparison. Structs that contains map, etc. needs deeper equality 
comparison.
s1:= MethodStruct1() //func() MyStruct
s2:= MethodStruct2() //func() *MyStruct

if s1 != *s2{
   //do something
}

i1:=MethodInterface1() //func() MyInterface
i2:=MethodInterface2() //func() MyInterface

if i1.Equal(i2){
   //do something
}


Finally, even if you are returning interface, you can still accept a subset 
of its interface (per Go's wisdom of accepting small interface).
type VolatileDataType interface{
   String() string
}

func NewVolatileDataType() VolatileDataType{
   //...
}

func Print(target Stringer){
  //...
}

Print(NewVolatileDataType()) //still works fine.


I wonder whether it is correct to conclude that in general people should 
return an interface, unless there is a real reason not to. Or better is "to 
accept and return interfaces".

Let me know what your experiences are regarding this matter.

Thanks.

Henry


-- 
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: Debugging in Go 1.8

[Nyah Check]

Hi JuciE,


> Nyah, there are several IDEs capable of controlling Delve under the hood
>> to debug Go programs. It works nicely.
>> If you are used to Visual Studio you will feel in home with VSCode. Even
>> shortcuts for debugging are the same.
>>
>>
I can't say much about IDEs since I don't really use them much. Tried Atom,
it was too slow for my system. I just stuck with Emacs and gedit while
running delve from my terminal. I don't currently know the recent updates
to delve. But I found it hard to debug a Go program not started by delve
itself. Since most of the functions and goroutines seen in the debugger
were not the implemented functions of my source code. I don't know if
anyone had that experience.

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.

Re: [go-nuts] Re: Debugging in Go 1.8

[ziffusion]

I tried delve with VSCode, and had a problem with GOPATH. For some reason 
the debugger saw a GOPATH that was different from the one set in the 
environment or VSCode settings.

Anyone have any input on this?

On Wednesday, March 1, 2017 at 6:18:43 PM UTC-5, JuciÊ Andrade wrote:
>
> Nyah, there are several IDEs capable of controlling Delve under the hood 
> to debug Go programs. It works nicely.
> If you are used to Visual Studio you will feel in home with VSCode. Even 
> shortcuts for debugging are the same.
>
> On Wednesday, March 1, 2017 at 4:32:09 PM UTC-3, Nyah Check wrote:
>>
>>
>>
>>> Great! Hope it continues to work for you. We're constantly working to 
>>> improve the debugging experience for Go, so feel free to reach out via our 
>>> mailing list or Github if you run into any issues or have any ideas for 
>>> improvement.
>>>
>>>
>> Will do 
>>
>

-- 
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: Debugging in Go 1.8

[ojucie]

Nyah, there are several IDEs capable of controlling Delve under the hood to 
debug Go programs. It works nicely.
If you are used to Visual Studio you will feel in home with VSCode. Even 
shortcuts for debugging are the same.

On Wednesday, March 1, 2017 at 4:32:09 PM UTC-3, Nyah Check wrote:
>
>
>
>> Great! Hope it continues to work for you. We're constantly working to 
>> improve the debugging experience for Go, so feel free to reach out via our 
>> mailing list or Github if you run into any issues or have any ideas for 
>> improvement.
>>
>>
> Will do 
>

-- 
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: Linking static c++ library with Go using SWIG

[Chun Zhang]

Quick update: 

The issue was resolved after a `go clean`...
Now everything build just as if the directives are passed through the CLI. 

I don't know what happened... 

Thank all for your help!


On Tuesday, February 28, 2017 at 2:06:20 PM UTC-5, Chun Zhang wrote:
>
> Hi, All, 
>
> I have googled quite a bit about this issue, there are some tutorials 
> online. But most of them targeted either at older go releases or C instead 
> of C++. 
>
> Can somebody please help me to figure out how to solve the following 
> issues?
>
> I have to use a static library, wrote in C++ in a go project. I have the 
> libcolor.a and the COLOR.h header file, the libcolor.a relies on some other 
> libraries, such as libboost_system.a, libxml2.a etc to build. 
>
> I wrote a libcolor.swigcxx file as follows:
> ---
> %module libcoror
>
> %{
> #include "include/COLOR.h"
> #include 
> #include 
>
> /* This is where we initialize any global parameters that are not 
> search-thread specific */
> extern void COLOR_init_global_config(int argc, char *argv[]);  // from the 
> COLOR.h file, which is one of the APIs I would like to use
>
> %}
>
> #include "include/COLOR.h"
> extern void COLOR_init_global_config(int argc, char *argv[]);
> ---
>
> An empty libcolor.go file with the following lines was manually created
>
> ---
> package libcolor
>
> // #cgo CFLAGS: -I .
> // #cgo CXXFLAGS: -std=c++11 <--- this does not seem to work
> // #cgo LDFLAGS: -L${SRCDIR}/lib/ -lCOLOR.a -lz <--- this is placed at the 
> correct place
> ---
>
> When I tried to build this using "go build -x" CLI, I hit the following 
> error:
>
> WORK=/tmp/go-build797493895
> mkdir -p $WORK/klow/libcolor/_obj/
> mkdir -p $WORK/klow/
> swig -version
> cd $WORK
> /usr/local/go/pkg/tool/linux_amd64/compile -o ./klow/libcolor/_obj/_go_.o 
> -trimpath . -p main -complete -buildid 
> 73a7f9534f74346db4b3e0f48875da9dbf8bc2fd -D _$WORK ./swig_intsize.go
> cd /home/chzhang/go/src/klow/libcolor
> swig -go -cgo -intgosize 64 -module libcolor -o 
> $WORK/klow/libcolor/_obj/libcolor_wrap.cxx -outdir 
> $WORK/klow/libcolor/_obj/ -c++ libcolor.swigcxx
> CGO_LDFLAGS="-g" "-O2" /usr/local/go/pkg/tool/linux_amd64/cgo -objdir 
> $WORK/klow/libcolor/_obj/ -importpath klow/libcolor -- -I 
> $WORK/klow/libcolor/_obj/ $WORK/klow/libcolor/_obj/libcolor.go
> cd $WORK
> gcc -fdebug-prefix-map=a=b -c trivial.c
> gcc -gno-record-gcc-switches -c trivial.c
> cd /home/chzhang/go/src/klow/libcolor
> gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
> $WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_main.o -c 
> $WORK/klow/libcolor/_obj/_cgo_main.c
> gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
> $WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_export.o 
> -c $WORK/klow/libcolor/_obj/_cgo_export.c
> gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
> $WORK/klow/libcolor/_obj/ -g -O2 -o 
> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.o
>  
> -c 
> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.c
> g++ -I . -fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
> $WORK/klow/libcolor/_obj/ -g -O2 -o 
> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor_wrap.cxx.o
>  
> -c $WORK/klow/libcolor/_obj/libcolor_wrap.cxx
> # klow/libcolor
> In file included from $WORK/klow/libcolor/_obj/libcolor_wrap.cxx:243:0:
> ./include/COLOR.h:13:43: warning: defaulted and deleted functions only 
> available with -std=c++11 or -std=gnu++11
>PerSessionData(const PerSessionData )=default;
>^
> ./include/COLOR.h:14:53: warning: defaulted and deleted functions only 
> available with -std=c++11 or -std=gnu++11
>PerSessionData& operator=(const PerSessionData)=default;
>  ^
> g++ -I . -fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -o 
> $WORK/klow/libcolor/_obj/_cgo_.o $WORK/klow/libcolor/_obj/_cgo_main.o 
> $WORK/klow/libcolor/_obj/_cgo_export.o 
> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.o
>  
> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor_wrap.cxx.o
>  
> -g -O2
> # klow/libcolor
> /tmp/go-build797493895/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor_wrap.cxx.o:
>  
> In function `_wrap_COLOR_init_global_config_libcolor_3cea422eb6211fe0':
> /tmp/go-build/klow/libcolor/_obj/libcolor_wrap.cxx:285: undefined 
> reference to `COLOR_init_global_config(int, char**)'
> collect2: error: ld returned 1 

[go-nuts] Re: Linking static c++ library with Go using SWIG

[therecipe]

ah, sorry I didn't properly read the whole thread before posting
if it works for you when you set the flags through the CLI, but not when 
you put them in a go file, then there is something wrong with how you 
embedded the flags in you go file.

like Ian said, you need to define the flags in a comment directly before 
using 
import "C"

so, something like this should work
package main

/*
#cgo LDFLAGS: -L${SRCDIR}kflow/libcolor/lib -lCOLOR
*/
import "C"


Am Mittwoch, 1. März 2017 21:02:25 UTC+1 schrieb Chun Zhang:
>
> Thanks! I didn't write out libboost etc just to make sure that at least 
> one lib is correctly linked, if so, I should see other link errors and I 
> can just keep passing in required libs. This is exactly what happens when I 
> pass CGO_LDFLAGS= explicitly in the CLI. 
>
> However, when using the directives in the go file, the CGO_LDFLAGS= as far 
> as I see in the `go build -x` log never includes any the link directives. 
>
> Regards,
> Chun
>
>
>
> On Wednesday, March 1, 2017 at 2:30:12 PM UTC-5, therecipe wrote:
>>
>> ah okay, I had problems with the ".a" suffix myself, so I though it was 
>> worth a shot.
>>
>> I just know that this
>> >//#cgo LDFLAGS: $GOPATH/src/kflow/libcolor/lib/libCOLOR 
>>
>> won't work, as the env variables won't be resolved by go afaik.
>>
>> maybe test it with an absolute path instead
>>
>> and/or use "go build -n" to see how go would invoke "link"
>>
>> and maybe you need to link against "libboost_system" and "libxml2" as 
>> well, if "libCOLOR" really depends on it.
>>
>>
>> Am Mittwoch, 1. März 2017 20:04:50 UTC+1 schrieb Chun Zhang:
>>>
>>> Yes, I tried quite a few varieties, such as:
>>> //#cgo LDFLAGS: $GOPATH/src/kflow/libcolor/lib/libCOLOR with/without .a
>>> //#cgo LDFLAGS: ${SRCDIR}kflow/libcolor/lib/libCOLOR with/without .a
>>> //#cgo LDFLAGS: -L${SRCDIR}kflow/libcolor/lib -l:libCOLOR with/without .a
>>> //#cgo LDFLAGS: -L${SRCDIR}kflow/libcolor/lib -lCOLOR with/without .a
>>>
>>> None above works for me so far, they are simply ignored during the 
>>> building process. I even played with the empty spaces at various places, 
>>> still no luck :(
>>>
>>> Thanks,
>>> Chun
>>>
>>>
>>> On Wednesday, March 1, 2017 at 1:57:15 PM UTC-5, therecipe wrote:

 did you try it without the ".a" suffix in the LDFLAGS?

 Am Dienstag, 28. Februar 2017 20:06:20 UTC+1 schrieb Chun Zhang:
>
> Hi, All, 
>
> I have googled quite a bit about this issue, there are some tutorials 
> online. But most of them targeted either at older go releases or C 
> instead 
> of C++. 
>
> Can somebody please help me to figure out how to solve the following 
> issues?
>
> I have to use a static library, wrote in C++ in a go project. I have 
> the libcolor.a and the COLOR.h header file, the libcolor.a relies on some 
> other libraries, such as libboost_system.a, libxml2.a etc to build. 
>
> I wrote a libcolor.swigcxx file as follows:
> ---
> %module libcoror
>
> %{
> #include "include/COLOR.h"
> #include 
> #include 
>
> /* This is where we initialize any global parameters that are not 
> search-thread specific */
> extern void COLOR_init_global_config(int argc, char *argv[]);  // from 
> the COLOR.h file, which is one of the APIs I would like to use
>
> %}
>
> #include "include/COLOR.h"
> extern void COLOR_init_global_config(int argc, char *argv[]);
> ---
>
> An empty libcolor.go file with the following lines was manually created
>
> ---
> package libcolor
>
> // #cgo CFLAGS: -I .
> // #cgo CXXFLAGS: -std=c++11 <--- this does not seem to work
> // #cgo LDFLAGS: -L${SRCDIR}/lib/ -lCOLOR.a -lz <--- this is placed at 
> the correct place
> ---
>
> When I tried to build this using "go build -x" CLI, I hit the 
> following error:
>
> WORK=/tmp/go-build797493895
> mkdir -p $WORK/klow/libcolor/_obj/
> mkdir -p $WORK/klow/
> swig -version
> cd $WORK
> /usr/local/go/pkg/tool/linux_amd64/compile -o 
> ./klow/libcolor/_obj/_go_.o -trimpath . -p main -complete -buildid 
> 73a7f9534f74346db4b3e0f48875da9dbf8bc2fd -D _$WORK ./swig_intsize.go
> cd /home/chzhang/go/src/klow/libcolor
> swig -go -cgo -intgosize 64 -module libcolor -o 
> $WORK/klow/libcolor/_obj/libcolor_wrap.cxx -outdir 
> $WORK/klow/libcolor/_obj/ -c++ libcolor.swigcxx
> CGO_LDFLAGS="-g" "-O2" /usr/local/go/pkg/tool/linux_amd64/cgo -objdir 
> $WORK/klow/libcolor/_obj/ -importpath klow/libcolor -- -I 
> $WORK/klow/libcolor/_obj/ $WORK/klow/libcolor/_obj/libcolor.go
> cd $WORK
> gcc -fdebug-prefix-map=a=b -c trivial.c
> gcc -gno-record-gcc-switches -c trivial.c
> cd /home/chzhang/go/src/klow/libcolor
> gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
> 

[go-nuts] Go Crypto/cipher and DES3 vs Openssl

[Rich]

I wrote an app that -- well does more than this but what I want it to do is 
to enable users to change their passwords, so I wrote the 
following: https://play.golang.org/p/RUbm8e_tJY  This seems to work, and i 
get my base64 encrypted password. When I test that against OpenSSL I don't 
get the same results.For example when I ran the code, it gave me this:

Decoded: WSAtwTSTMVydiJLx00ATfp8grl4KbpgB to Abc.1234


So now if I take the WSAtwTSTMVydiJLx00ATfp8grl4KbpgB I should be able to 
decrypt that with OpenSSL:

echo "WSAtwTSTMVydiJLx00ATfp8grl4KbpgB" | openssl des3 -d -nosalt -a 

enter des-ede3-cbc decryption password:
bad decrypt
140331031709344:error:06065064:digital envelope 
routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539:
>�x�}9L
   �9[


Anyone know of a better way to test to make sure the code is correct and the 
base64 string that comes out can be decrypted by something other than another 
go program?


Thanks,


Rich

-- 
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: Linking static c++ library with Go using SWIG

[Chun Zhang]

Thanks! I didn't write out libboost etc just to make sure that at least one 
lib is correctly linked, if so, I should see other link errors and I can 
just keep passing in required libs. This is exactly what happens when I 
pass CGO_LDFLAGS= explicitly in the CLI. 

However, when using the directives in the go file, the CGO_LDFLAGS= as far 
as I see in the `go build -x` log never includes any the link directives. 

Regards,
Chun



On Wednesday, March 1, 2017 at 2:30:12 PM UTC-5, therecipe wrote:
>
> ah okay, I had problems with the ".a" suffix myself, so I though it was 
> worth a shot.
>
> I just know that this
> >//#cgo LDFLAGS: $GOPATH/src/kflow/libcolor/lib/libCOLOR 
>
> won't work, as the env variables won't be resolved by go afaik.
>
> maybe test it with an absolute path instead
>
> and/or use "go build -n" to see how go would invoke "link"
>
> and maybe you need to link against "libboost_system" and "libxml2" as 
> well, if "libCOLOR" really depends on it.
>
>
> Am Mittwoch, 1. März 2017 20:04:50 UTC+1 schrieb Chun Zhang:
>>
>> Yes, I tried quite a few varieties, such as:
>> //#cgo LDFLAGS: $GOPATH/src/kflow/libcolor/lib/libCOLOR with/without .a
>> //#cgo LDFLAGS: ${SRCDIR}kflow/libcolor/lib/libCOLOR with/without .a
>> //#cgo LDFLAGS: -L${SRCDIR}kflow/libcolor/lib -l:libCOLOR with/without .a
>> //#cgo LDFLAGS: -L${SRCDIR}kflow/libcolor/lib -lCOLOR with/without .a
>>
>> None above works for me so far, they are simply ignored during the 
>> building process. I even played with the empty spaces at various places, 
>> still no luck :(
>>
>> Thanks,
>> Chun
>>
>>
>> On Wednesday, March 1, 2017 at 1:57:15 PM UTC-5, therecipe wrote:
>>>
>>> did you try it without the ".a" suffix in the LDFLAGS?
>>>
>>> Am Dienstag, 28. Februar 2017 20:06:20 UTC+1 schrieb Chun Zhang:

 Hi, All, 

 I have googled quite a bit about this issue, there are some tutorials 
 online. But most of them targeted either at older go releases or C instead 
 of C++. 

 Can somebody please help me to figure out how to solve the following 
 issues?

 I have to use a static library, wrote in C++ in a go project. I have 
 the libcolor.a and the COLOR.h header file, the libcolor.a relies on some 
 other libraries, such as libboost_system.a, libxml2.a etc to build. 

 I wrote a libcolor.swigcxx file as follows:
 ---
 %module libcoror

 %{
 #include "include/COLOR.h"
 #include 
 #include 

 /* This is where we initialize any global parameters that are not 
 search-thread specific */
 extern void COLOR_init_global_config(int argc, char *argv[]);  // from 
 the COLOR.h file, which is one of the APIs I would like to use

 %}

 #include "include/COLOR.h"
 extern void COLOR_init_global_config(int argc, char *argv[]);
 ---

 An empty libcolor.go file with the following lines was manually created

 ---
 package libcolor

 // #cgo CFLAGS: -I .
 // #cgo CXXFLAGS: -std=c++11 <--- this does not seem to work
 // #cgo LDFLAGS: -L${SRCDIR}/lib/ -lCOLOR.a -lz <--- this is placed at 
 the correct place
 ---

 When I tried to build this using "go build -x" CLI, I hit the following 
 error:

 WORK=/tmp/go-build797493895
 mkdir -p $WORK/klow/libcolor/_obj/
 mkdir -p $WORK/klow/
 swig -version
 cd $WORK
 /usr/local/go/pkg/tool/linux_amd64/compile -o 
 ./klow/libcolor/_obj/_go_.o -trimpath . -p main -complete -buildid 
 73a7f9534f74346db4b3e0f48875da9dbf8bc2fd -D _$WORK ./swig_intsize.go
 cd /home/chzhang/go/src/klow/libcolor
 swig -go -cgo -intgosize 64 -module libcolor -o 
 $WORK/klow/libcolor/_obj/libcolor_wrap.cxx -outdir 
 $WORK/klow/libcolor/_obj/ -c++ libcolor.swigcxx
 CGO_LDFLAGS="-g" "-O2" /usr/local/go/pkg/tool/linux_amd64/cgo -objdir 
 $WORK/klow/libcolor/_obj/ -importpath klow/libcolor -- -I 
 $WORK/klow/libcolor/_obj/ $WORK/klow/libcolor/_obj/libcolor.go
 cd $WORK
 gcc -fdebug-prefix-map=a=b -c trivial.c
 gcc -gno-record-gcc-switches -c trivial.c
 cd /home/chzhang/go/src/klow/libcolor
 gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
 -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
 $WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_main.o 
 -c 
 $WORK/klow/libcolor/_obj/_cgo_main.c
 gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
 -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
 $WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_export.o 
 -c $WORK/klow/libcolor/_obj/_cgo_export.c
 gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
 -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
 $WORK/klow/libcolor/_obj/ -g -O2 -o 
 

Re: [go-nuts] Re: Debugging in Go 1.8

[Nyah Check]

>
> Great! Hope it continues to work for you. We're constantly working to
> improve the debugging experience for Go, so feel free to reach out via our
> mailing list or Github if you run into any issues or have any ideas for
> improvement.
>
>
Will do

-- 
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: Linking static c++ library with Go using SWIG

[therecipe]

ah okay, I had problems with the ".a" suffix myself, so I though it was 
worth a shot.

I just know that this
>//#cgo LDFLAGS: $GOPATH/src/kflow/libcolor/lib/libCOLOR 

won't work, as the env variables won't be resolved by go afaik.

maybe test it with an absolute path instead

and/or use "go build -n" to see how go would invoke "link"

and maybe you need to link against "libboost_system" and "libxml2" as well, 
if "libCOLOR" really depends on it.


Am Mittwoch, 1. März 2017 20:04:50 UTC+1 schrieb Chun Zhang:
>
> Yes, I tried quite a few varieties, such as:
> //#cgo LDFLAGS: $GOPATH/src/kflow/libcolor/lib/libCOLOR with/without .a
> //#cgo LDFLAGS: ${SRCDIR}kflow/libcolor/lib/libCOLOR with/without .a
> //#cgo LDFLAGS: -L${SRCDIR}kflow/libcolor/lib -l:libCOLOR with/without .a
> //#cgo LDFLAGS: -L${SRCDIR}kflow/libcolor/lib -lCOLOR with/without .a
>
> None above works for me so far, they are simply ignored during the 
> building process. I even played with the empty spaces at various places, 
> still no luck :(
>
> Thanks,
> Chun
>
>
> On Wednesday, March 1, 2017 at 1:57:15 PM UTC-5, therecipe wrote:
>>
>> did you try it without the ".a" suffix in the LDFLAGS?
>>
>> Am Dienstag, 28. Februar 2017 20:06:20 UTC+1 schrieb Chun Zhang:
>>>
>>> Hi, All, 
>>>
>>> I have googled quite a bit about this issue, there are some tutorials 
>>> online. But most of them targeted either at older go releases or C instead 
>>> of C++. 
>>>
>>> Can somebody please help me to figure out how to solve the following 
>>> issues?
>>>
>>> I have to use a static library, wrote in C++ in a go project. I have the 
>>> libcolor.a and the COLOR.h header file, the libcolor.a relies on some other 
>>> libraries, such as libboost_system.a, libxml2.a etc to build. 
>>>
>>> I wrote a libcolor.swigcxx file as follows:
>>> ---
>>> %module libcoror
>>>
>>> %{
>>> #include "include/COLOR.h"
>>> #include 
>>> #include 
>>>
>>> /* This is where we initialize any global parameters that are not 
>>> search-thread specific */
>>> extern void COLOR_init_global_config(int argc, char *argv[]);  // from 
>>> the COLOR.h file, which is one of the APIs I would like to use
>>>
>>> %}
>>>
>>> #include "include/COLOR.h"
>>> extern void COLOR_init_global_config(int argc, char *argv[]);
>>> ---
>>>
>>> An empty libcolor.go file with the following lines was manually created
>>>
>>> ---
>>> package libcolor
>>>
>>> // #cgo CFLAGS: -I .
>>> // #cgo CXXFLAGS: -std=c++11 <--- this does not seem to work
>>> // #cgo LDFLAGS: -L${SRCDIR}/lib/ -lCOLOR.a -lz <--- this is placed at 
>>> the correct place
>>> ---
>>>
>>> When I tried to build this using "go build -x" CLI, I hit the following 
>>> error:
>>>
>>> WORK=/tmp/go-build797493895
>>> mkdir -p $WORK/klow/libcolor/_obj/
>>> mkdir -p $WORK/klow/
>>> swig -version
>>> cd $WORK
>>> /usr/local/go/pkg/tool/linux_amd64/compile -o 
>>> ./klow/libcolor/_obj/_go_.o -trimpath . -p main -complete -buildid 
>>> 73a7f9534f74346db4b3e0f48875da9dbf8bc2fd -D _$WORK ./swig_intsize.go
>>> cd /home/chzhang/go/src/klow/libcolor
>>> swig -go -cgo -intgosize 64 -module libcolor -o 
>>> $WORK/klow/libcolor/_obj/libcolor_wrap.cxx -outdir 
>>> $WORK/klow/libcolor/_obj/ -c++ libcolor.swigcxx
>>> CGO_LDFLAGS="-g" "-O2" /usr/local/go/pkg/tool/linux_amd64/cgo -objdir 
>>> $WORK/klow/libcolor/_obj/ -importpath klow/libcolor -- -I 
>>> $WORK/klow/libcolor/_obj/ $WORK/klow/libcolor/_obj/libcolor.go
>>> cd $WORK
>>> gcc -fdebug-prefix-map=a=b -c trivial.c
>>> gcc -gno-record-gcc-switches -c trivial.c
>>> cd /home/chzhang/go/src/klow/libcolor
>>> gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
>>> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
>>> $WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_main.o -c 
>>> $WORK/klow/libcolor/_obj/_cgo_main.c
>>> gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
>>> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
>>> $WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_export.o 
>>> -c $WORK/klow/libcolor/_obj/_cgo_export.c
>>> gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
>>> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
>>> $WORK/klow/libcolor/_obj/ -g -O2 -o 
>>> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.o
>>>  
>>> -c 
>>> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.c
>>> g++ -I . -fPIC -m64 -pthread -fmessage-length=0 
>>> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
>>> $WORK/klow/libcolor/_obj/ -g -O2 -o 
>>> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor_wrap.cxx.o
>>>  
>>> -c $WORK/klow/libcolor/_obj/libcolor_wrap.cxx
>>> # klow/libcolor
>>> In file included from $WORK/klow/libcolor/_obj/libcolor_wrap.cxx:243:0:
>>> ./include/COLOR.h:13:43: warning: defaulted and deleted functions only 
>>> 

[go-nuts] Re: Linking static c++ library with Go using SWIG

[Chun Zhang]

Yes, I tried quite a few varieties, such as:
//#cgo LDFLAGS: $GOPATH/src/kflow/libcolor/lib/libCOLOR with/without .a
//#cgo LDFLAGS: ${SRCDIR}kflow/libcolor/lib/libCOLOR with/without .a
//#cgo LDFLAGS: -L${SRCDIR}kflow/libcolor/lib -l:libCOLOR with/without .a
//#cgo LDFLAGS: -L${SRCDIR}kflow/libcolor/lib -lCOLOR with/without .a

None above works for me so far, they are simply ignored during the building 
process. I even played with the empty spaces at various places, still no 
luck :(

Thanks,
Chun


On Wednesday, March 1, 2017 at 1:57:15 PM UTC-5, therecipe wrote:
>
> did you try it without the ".a" suffix in the LDFLAGS?
>
> Am Dienstag, 28. Februar 2017 20:06:20 UTC+1 schrieb Chun Zhang:
>>
>> Hi, All, 
>>
>> I have googled quite a bit about this issue, there are some tutorials 
>> online. But most of them targeted either at older go releases or C instead 
>> of C++. 
>>
>> Can somebody please help me to figure out how to solve the following 
>> issues?
>>
>> I have to use a static library, wrote in C++ in a go project. I have the 
>> libcolor.a and the COLOR.h header file, the libcolor.a relies on some other 
>> libraries, such as libboost_system.a, libxml2.a etc to build. 
>>
>> I wrote a libcolor.swigcxx file as follows:
>> ---
>> %module libcoror
>>
>> %{
>> #include "include/COLOR.h"
>> #include 
>> #include 
>>
>> /* This is where we initialize any global parameters that are not 
>> search-thread specific */
>> extern void COLOR_init_global_config(int argc, char *argv[]);  // from 
>> the COLOR.h file, which is one of the APIs I would like to use
>>
>> %}
>>
>> #include "include/COLOR.h"
>> extern void COLOR_init_global_config(int argc, char *argv[]);
>> ---
>>
>> An empty libcolor.go file with the following lines was manually created
>>
>> ---
>> package libcolor
>>
>> // #cgo CFLAGS: -I .
>> // #cgo CXXFLAGS: -std=c++11 <--- this does not seem to work
>> // #cgo LDFLAGS: -L${SRCDIR}/lib/ -lCOLOR.a -lz <--- this is placed at 
>> the correct place
>> ---
>>
>> When I tried to build this using "go build -x" CLI, I hit the following 
>> error:
>>
>> WORK=/tmp/go-build797493895
>> mkdir -p $WORK/klow/libcolor/_obj/
>> mkdir -p $WORK/klow/
>> swig -version
>> cd $WORK
>> /usr/local/go/pkg/tool/linux_amd64/compile -o ./klow/libcolor/_obj/_go_.o 
>> -trimpath . -p main -complete -buildid 
>> 73a7f9534f74346db4b3e0f48875da9dbf8bc2fd -D _$WORK ./swig_intsize.go
>> cd /home/chzhang/go/src/klow/libcolor
>> swig -go -cgo -intgosize 64 -module libcolor -o 
>> $WORK/klow/libcolor/_obj/libcolor_wrap.cxx -outdir 
>> $WORK/klow/libcolor/_obj/ -c++ libcolor.swigcxx
>> CGO_LDFLAGS="-g" "-O2" /usr/local/go/pkg/tool/linux_amd64/cgo -objdir 
>> $WORK/klow/libcolor/_obj/ -importpath klow/libcolor -- -I 
>> $WORK/klow/libcolor/_obj/ $WORK/klow/libcolor/_obj/libcolor.go
>> cd $WORK
>> gcc -fdebug-prefix-map=a=b -c trivial.c
>> gcc -gno-record-gcc-switches -c trivial.c
>> cd /home/chzhang/go/src/klow/libcolor
>> gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
>> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
>> $WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_main.o -c 
>> $WORK/klow/libcolor/_obj/_cgo_main.c
>> gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
>> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
>> $WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_export.o 
>> -c $WORK/klow/libcolor/_obj/_cgo_export.c
>> gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
>> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
>> $WORK/klow/libcolor/_obj/ -g -O2 -o 
>> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.o
>>  
>> -c 
>> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.c
>> g++ -I . -fPIC -m64 -pthread -fmessage-length=0 
>> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
>> $WORK/klow/libcolor/_obj/ -g -O2 -o 
>> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor_wrap.cxx.o
>>  
>> -c $WORK/klow/libcolor/_obj/libcolor_wrap.cxx
>> # klow/libcolor
>> In file included from $WORK/klow/libcolor/_obj/libcolor_wrap.cxx:243:0:
>> ./include/COLOR.h:13:43: warning: defaulted and deleted functions only 
>> available with -std=c++11 or -std=gnu++11
>>PerSessionData(const PerSessionData )=default;
>>^
>> ./include/COLOR.h:14:53: warning: defaulted and deleted functions only 
>> available with -std=c++11 or -std=gnu++11
>>PerSessionData& operator=(const PerSessionData)=default;
>>  ^
>> g++ -I . -fPIC -m64 -pthread -fmessage-length=0 
>> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -o 
>> $WORK/klow/libcolor/_obj/_cgo_.o $WORK/klow/libcolor/_obj/_cgo_main.o 
>> $WORK/klow/libcolor/_obj/_cgo_export.o 
>> 

[go-nuts] Re: Linking static c++ library with Go using SWIG

[therecipe]

did you try it without the ".a" suffix in the LDFLAGS?

Am Dienstag, 28. Februar 2017 20:06:20 UTC+1 schrieb Chun Zhang:
>
> Hi, All, 
>
> I have googled quite a bit about this issue, there are some tutorials 
> online. But most of them targeted either at older go releases or C instead 
> of C++. 
>
> Can somebody please help me to figure out how to solve the following 
> issues?
>
> I have to use a static library, wrote in C++ in a go project. I have the 
> libcolor.a and the COLOR.h header file, the libcolor.a relies on some other 
> libraries, such as libboost_system.a, libxml2.a etc to build. 
>
> I wrote a libcolor.swigcxx file as follows:
> ---
> %module libcoror
>
> %{
> #include "include/COLOR.h"
> #include 
> #include 
>
> /* This is where we initialize any global parameters that are not 
> search-thread specific */
> extern void COLOR_init_global_config(int argc, char *argv[]);  // from the 
> COLOR.h file, which is one of the APIs I would like to use
>
> %}
>
> #include "include/COLOR.h"
> extern void COLOR_init_global_config(int argc, char *argv[]);
> ---
>
> An empty libcolor.go file with the following lines was manually created
>
> ---
> package libcolor
>
> // #cgo CFLAGS: -I .
> // #cgo CXXFLAGS: -std=c++11 <--- this does not seem to work
> // #cgo LDFLAGS: -L${SRCDIR}/lib/ -lCOLOR.a -lz <--- this is placed at the 
> correct place
> ---
>
> When I tried to build this using "go build -x" CLI, I hit the following 
> error:
>
> WORK=/tmp/go-build797493895
> mkdir -p $WORK/klow/libcolor/_obj/
> mkdir -p $WORK/klow/
> swig -version
> cd $WORK
> /usr/local/go/pkg/tool/linux_amd64/compile -o ./klow/libcolor/_obj/_go_.o 
> -trimpath . -p main -complete -buildid 
> 73a7f9534f74346db4b3e0f48875da9dbf8bc2fd -D _$WORK ./swig_intsize.go
> cd /home/chzhang/go/src/klow/libcolor
> swig -go -cgo -intgosize 64 -module libcolor -o 
> $WORK/klow/libcolor/_obj/libcolor_wrap.cxx -outdir 
> $WORK/klow/libcolor/_obj/ -c++ libcolor.swigcxx
> CGO_LDFLAGS="-g" "-O2" /usr/local/go/pkg/tool/linux_amd64/cgo -objdir 
> $WORK/klow/libcolor/_obj/ -importpath klow/libcolor -- -I 
> $WORK/klow/libcolor/_obj/ $WORK/klow/libcolor/_obj/libcolor.go
> cd $WORK
> gcc -fdebug-prefix-map=a=b -c trivial.c
> gcc -gno-record-gcc-switches -c trivial.c
> cd /home/chzhang/go/src/klow/libcolor
> gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
> $WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_main.o -c 
> $WORK/klow/libcolor/_obj/_cgo_main.c
> gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
> $WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_export.o 
> -c $WORK/klow/libcolor/_obj/_cgo_export.c
> gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
> $WORK/klow/libcolor/_obj/ -g -O2 -o 
> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.o
>  
> -c 
> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.c
> g++ -I . -fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
> $WORK/klow/libcolor/_obj/ -g -O2 -o 
> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor_wrap.cxx.o
>  
> -c $WORK/klow/libcolor/_obj/libcolor_wrap.cxx
> # klow/libcolor
> In file included from $WORK/klow/libcolor/_obj/libcolor_wrap.cxx:243:0:
> ./include/COLOR.h:13:43: warning: defaulted and deleted functions only 
> available with -std=c++11 or -std=gnu++11
>PerSessionData(const PerSessionData )=default;
>^
> ./include/COLOR.h:14:53: warning: defaulted and deleted functions only 
> available with -std=c++11 or -std=gnu++11
>PerSessionData& operator=(const PerSessionData)=default;
>  ^
> g++ -I . -fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -o 
> $WORK/klow/libcolor/_obj/_cgo_.o $WORK/klow/libcolor/_obj/_cgo_main.o 
> $WORK/klow/libcolor/_obj/_cgo_export.o 
> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.o
>  
> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor_wrap.cxx.o
>  
> -g -O2
> # klow/libcolor
> /tmp/go-build797493895/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor_wrap.cxx.o:
>  
> In function `_wrap_COLOR_init_global_config_libcolor_3cea422eb6211fe0':
> /tmp/go-build/klow/libcolor/_obj/libcolor_wrap.cxx:285: undefined 
> reference to `COLOR_init_global_config(int, char**)'
> collect2: error: ld returned 1 exit status
>
>
> Looks like there are two errors:
> 1, the C++11 warning
> 2, the linker can't find the function COLOR_init_global_config in the 

Re: [go-nuts] Linking static c++ library with Go using SWIG

[Chun Zhang]

Ian, thanks for the explanation!

I tried to split the go/swigcxx code and c++ code to two different 
directories as the example given by Stephen earlier. That didn't work. No 
matter what I do, I don't see the flags being passed to the compiler. 

For now, I will simply use the build script and passing all compiler 
parameters explicitly. But this does not seem to be an optimal solution. If 
there is anything else that I can try, please let me know. 

Thanks,
Chun



On Wednesday, March 1, 2017 at 1:20:16 PM UTC-5, Ian Lance Taylor wrote:
>
> On Wed, Mar 1, 2017 at 10:16 AM, Chun Zhang  > wrote: 
> > Thanks Ian! But that does not seem to be the issue, I changed 
> libcolor.go to 
> > color.go and still get the same error. 
> > 
> > However, I did made tiny progress, I can specifically pass the 
> parameters in 
> > the CLI and get it build, for example 
> > 
> > CGO_CXXFLAGS="-I$GOPATH/src/kflow/libcolor/include" 
> > CGO_LDFLAGS="-L$GOPATH/src/kflow/libcolor/lib -l:libCOLOR.a 
> > -l:libboost_system.a -l:libboost_regex.a -l:libboost_program_options.a 
> > -l:libboost_filesystem.a -l:libxml2.a -lz" go build -x 
> > 
> > but, the installed libcolor.a in the pkg directory looks suspiciously 
> small, 
> > only 55k, while libCOLOR.a itself is roughly 300MB. I wrote a simple 
> main 
> > file, the application is around 140MB. The numbers do not seem to agree 
> with 
> > each other. 
>
> That does not necessarily indicate a problem.  When the linker sees a 
> .a file, it only pulls in referenced symbols, not the entire archive. 
> So if your program only uses a small part of libCOLOR.a, it would be 
> natural for the program to be smaller than libCOLOR.a.  I don't know 
> whether there is a problem there or not, but the file size doesn't 
> necessarily mean that there is. 
>
> > I do notice though, the 
> > GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
> > -fdebug-prefix-map=/tmp/go-build471211808=/tmp/go-build 
> > -gno-record-gcc-switches" 
> > in the `go env` output has the -fdebug-prefix-map changed each and 
> > everytime, is that expected? 
>
> Yes.  That option is keeping the Go temporary directory out of the 
> debug info stored in the object file.  This helps makes builds 
> reproducible. 
>
> 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] Linking static c++ library with Go using SWIG

[Ian Lance Taylor]

On Wed, Mar 1, 2017 at 10:16 AM, Chun Zhang  wrote:
> Thanks Ian! But that does not seem to be the issue, I changed libcolor.go to
> color.go and still get the same error.
>
> However, I did made tiny progress, I can specifically pass the parameters in
> the CLI and get it build, for example
>
> CGO_CXXFLAGS="-I$GOPATH/src/kflow/libcolor/include"
> CGO_LDFLAGS="-L$GOPATH/src/kflow/libcolor/lib -l:libCOLOR.a
> -l:libboost_system.a -l:libboost_regex.a -l:libboost_program_options.a
> -l:libboost_filesystem.a -l:libxml2.a -lz" go build -x
>
> but, the installed libcolor.a in the pkg directory looks suspiciously small,
> only 55k, while libCOLOR.a itself is roughly 300MB. I wrote a simple main
> file, the application is around 140MB. The numbers do not seem to agree with
> each other.

That does not necessarily indicate a problem.  When the linker sees a
.a file, it only pulls in referenced symbols, not the entire archive.
So if your program only uses a small part of libCOLOR.a, it would be
natural for the program to be smaller than libCOLOR.a.  I don't know
whether there is a problem there or not, but the file size doesn't
necessarily mean that there is.

> I do notice though, the
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=/tmp/go-build471211808=/tmp/go-build
> -gno-record-gcc-switches"
> in the `go env` output has the -fdebug-prefix-map changed each and
> everytime, is that expected?

Yes.  That option is keeping the Go temporary directory out of the
debug info stored in the object file.  This helps makes builds
reproducible.

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] Linking static c++ library with Go using SWIG

[Ian Lance Taylor]

On Wed, Mar 1, 2017 at 8:13 AM, Chun Zhang  wrote:
> Just wondering, is there any chance that I didn't place some file in the
> correct place? The directory tree is as follows,
> ├── bin
> ├── example
> │   └── COLOR_test
> │   ├── COLOR_test.cpp
> │   └── SessionKey.hpp
> ├── include
> │   └── COLOR.h
> ├── lib
> │   ├── libboost_filesystem.a
> │   ├── libCOLOR.a
> │   └── libxml2.a
> ├── libcolor
> ├── libcolor.go
> ├── libcolor.swigcxx
> ├── README
>
> When I issue `go build -x`, go and swig insists to generate another
> libcolor.go file in the tmp $WORK directory, thus none of the directives
> defined in above libcolor.go file is picked up.

It's possible that there is a bug such that it won't work to have both
x.swigcxx and x.go in the same package.  Maybe you should rename
libcolor.go.

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] Re: Access COM interfaces, methods from whip.dll

[Irish Go]

Sorry, i meant external libs like cgo or go-ole...

On Wednesday, March 1, 2017 at 3:04:36 PM UTC, Irish Go wrote:
>
> Hi There,
>
> Is there any way to access using syscall, interfaces and 
> methods/properties from wuapi.dll (Windows Update Agent) just using the 
> standard syscall lib. (without using any external libs like cog or go-ole)?
>
> The aim is to retrieve a list of updates/hotfixes installed on a server.
>
> Any tips would be welcome
>
> 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.

Re: [go-nuts] Linking static c++ library with Go using SWIG

[Chun Zhang]

Just wondering, is there any chance that I didn't place some file in the 
correct place? The directory tree is as follows, 
├── bin
├── example
│   └── COLOR_test
│   ├── COLOR_test.cpp
│   └── SessionKey.hpp
├── include
│   └── COLOR.h
├── lib
│   ├── libboost_filesystem.a
│   ├── libCOLOR.a
│   └── libxml2.a
├── libcolor
├── libcolor.go
├── libcolor.swigcxx
├── README

When I issue `go build -x`, go and swig insists to generate another 
libcolor.go file in the tmp $WORK directory, thus none of the directives 
defined in above libcolor.go file is picked up. 

Any help will be appreciated. 

Thanks,
Chun



On Tuesday, February 28, 2017 at 2:49:19 PM UTC-5, Chun Zhang wrote:
>
> Thank you for your reply! I read a few posts between you and Stephen 
> before posting this. 
>
> Sorry, it was a bad copy and paste. 
>
> I did have the import "C" line in the file. But I have the same error. 
>
> I can "go build libcolor.go" itself with no error. But that does not seem 
> to build the whole library.
>
> Best Regards,
> Chun
>
> On Tuesday, February 28, 2017 at 2:44:21 PM UTC-5, Ian Lance Taylor wrote:
>>
>> On Tue, Feb 28, 2017 at 11:04 AM, Chun Zhang  wrote: 
>> > 
>> > An empty libcolor.go file with the following lines was manually created 
>> > 
>> > --- 
>> > package libcolor 
>> > 
>> > // #cgo CFLAGS: -I . 
>> > // #cgo CXXFLAGS: -std=c++11 <--- this does not seem to work 
>> > // #cgo LDFLAGS: -L${SRCDIR}/lib/ -lCOLOR.a -lz <--- this is placed at 
>> the 
>> > correct place 
>>
>> Note that this is only effective if those comments appear directly 
>> before an `import "C"` line. 
>>
>> 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] Access COM interfaces, methods from whip.dll

[Irish Go]

Hi There,

Is there any way to access using syscall, interfaces and methods/properties 
from wuapi.dll (Windows Update Agent) just using the standard syscall lib. 
(without using any external libs like cog or go-ole)?

The aim is to retrieve a list of updates/hotfixes installed on a server.

Any tips would be welcome

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.

Re: [go-nuts] Debugging in Go 1.8

[Nyah Check]

Hi,


> I'm sorry, I'm not sure what you mean by "the go debugger" or "GDG".
>
I meant "gdb" sorry about that.


>
> The compiler team continues to work on improving the quality of the
> generated DWARF information.  It's not a high priority effort, though.
> And I'm sure the Delve developers are continuing to improve Delve.
> Other than that, I'm not aware of any plans for a better debugging
> experience.  It may help to file bugs, with test cases, for specific
> issues that you see.
>

Alright, I see

Thanks,



-- 
"The heaviest penalty for declining to rule is to be ruled by someone
inferior to yourself." --*Plato*

-- 
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] plugin questions....

[Ian Lance Taylor]

On Tue, Feb 28, 2017 at 10:55 PM, Basile Starynkevitch
 wrote:
>
> On Wednesday, March 1, 2017 at 7:17:42 AM UTC+1, Ian Lance Taylor wrote:
>>
>> On Tue, Feb 28, 2017 at 12:44 PM, Basile Starynkevitch
>>  wrote:
>> > Can the packages defined in one plugin be visible from plugins loaded
>> > afterwards? I'm thinking of a dlopen with  RTLD_GLOBAL flag in C
>> > parlance.
>>
>> I'm not sure this really makes sense in a Go context.  I'm not sure
>> how you would refer to those symbols.
>
>
> The scenario would be the following:
>
> a plugin P1 defines the P1_foo () function. P1 is loaded (and I would like
> the name to be visible afterwards, see below). We can assume that the
> loading program & process does not have any P1_foo in it.
>
> later, another plugin P2 defines the P2_bar() function which calls P1_foo(),
> and I would like that to mean the P1_foo() function inside P1. It seems that
> this is not possible currently. (of course loading P2 before loading P1
> should fail). I don't understand why would that not make any sense.

Go, unlike C, does not have the notion of an external symbol that is
defined somewhere else to be discovered at link time.  In Go all
symbols come from imported packages.  So if P2 does not import P1,
then P2 can not refer to P1_foo.

That said, you could probably get something like this to work by using
the //go:linkname compiler directive, which is available if you import
the unsafe package.  See https://golang.org/cmd/compile.

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] Debugging in Go 1.8

[Ian Lance Taylor]

On Wed, Mar 1, 2017 at 5:41 AM, Nyah Check  wrote:
> I'm currently reading the Go 1.8 release documentation; I've not seen any
> additional tools to facilitate Go debugging. I've mostly been comfortable
> with delve. But I just wish to know if the golang-devs have any plans of
> upgrading the go debugger? GDG sucks for me already.

I'm sorry, I'm not sure what you mean by "the go debugger" or "GDG".

The compiler team continues to work on improving the quality of the
generated DWARF information.  It's not a high priority effort, though.
And I'm sure the Delve developers are continuing to improve Delve.
Other than that, I'm not aware of any plans for a better debugging
experience.  It may help to file bugs, with test cases, for specific
issues that you see.

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] Investigating Go memory leaks

[Maria Borysova]

While loadtesting Acra with our team, we had to dive deep into #Go 
 memory management. Here's what we 
did, so you don't have to: 
https://www.cossacklabs.com/blog/investigating-go-memory-leaks.html

-- 
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: Can ServerMux serve two different handler functions on / and a path beyond / ?

[howardcshaw]

I think at that point you have to step up to one of the muxers - Gorilla is 
a popular choice in the ecosystem. https://github.com/gorilla/mux

Their example:

func main() {
r := mux.NewRouter()
r.HandleFunc("/", HomeHandler)
r.HandleFunc("/products", ProductsHandler)
r.HandleFunc("/articles", ArticlesHandler)
http.Handle("/", r)
}

httprouter is also popular, and there are others, see Awesome Go for more.

Howard 

-- 
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] Regarding os.Stdout

[Konstantin Khomoutov]

On Sun, 26 Feb 2017 16:53:48 -0800 (PST)
Curtis Paul  wrote:

> I have the following code.
> 
> How might I parse the os.Stdout data into a map?
> 
> Basically I want to read audio interfaces and put them in some sort
> of data structure.

Can you elaborate on your approach a bit?

The thing is, portaudio.HostApis() already returns you a value which
is "some sort of data structure" -- a slice of pointers to values of
type portaudio.HostApiInfo (which itself is a struct), so in your
code...

> package main
> 
> import (
> "github.com/gordonklaus/portaudio"
[...]
> hs, err := portaudio.HostApis()

...the hs variable already contains a list of supported host APIs.

Now you do

[...]
> err = tmpl.Execute(os.Stdout, hs)
[...]

which supposedly should render your template with the values in hs.

That's sort of sensible, but in the opening passage of your mail you
state that you want to "...parse the os.Stdout data into a map" which
implies you now want to read the data rendered by the template and
parse it back?  But this bears the question: why the heck you'd want to
do that if you already has the data on your hand -- the data you
submitted to the templating engine?

What's your actual intent?

-- 
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] Support for the race detector on ARM

['Dmitry Vyukov' via golang-nuts]

On Wed, Mar 1, 2017 at 2:00 AM, Owen Waller  wrote:
> Hi Dimitry,
>
> The make goal of the current mapping is to make MemToShadow function
> fast (no memory accesses, no branching).
> For starters you can take any simple mapping at the cost making
> MemToShadow slower.
>
>
> OK that's good. As I wasn't intending to do anything apart from put in the
> new memory map, rebuild things and then try it against some sort of hello
> world example.
>
> I do not want to be changing any code beyond this if a can avoid it.
>
>
> and do you want
> to take a stab at what the mappings might be for a 32 bit system?
>
>
> I don't have time to work on this.
>
>
> I understand that. But at the minute, I don't understand how the numbers in
> the memory map are arrived at. Is the process documented somewhere so I can
> work this out for myself?


The mapping needs to satisfy the following requirements:
1. For all user memory regions there are 4x shadow regions.
2. For all user memory regions there are 0.5x meta shadow regions.
3. There is a region for thread traces.
4. +maybe a region for internal heap.


> You need clang as it contains the master copy of tsan runtime. Here
> are some building instructions:
> https://github.com/google/sanitizers/wiki/AddressSanitizerHowToBuild
>
>
> Thank you for this. It looks like I'll need to set up clang etc first.
>
> Owen

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