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

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

Re: [go-nuts] Re: the case for returning interface vs struct

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

[go-nuts] Re: why the second memory allocation is blocked?

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

[go-nuts] Re: the case for returning interface vs struct

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

[go-nuts] the case for returning interface vs struct

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

[go-nuts] Re: why the second memory allocation is blocked?

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

[go-nuts] Re: why the second memory allocation is blocked?

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

[go-nuts] Re: why the second memory allocation is blocked?

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

[go-nuts] Re: why the second memory allocation is blocked?

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

[go-nuts] Re: why the second memory allocation is blocked?

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

[go-nuts] why the second memory allocation is blocked?

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()

[go-nuts] the case for returning interface vs struct

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

[go-nuts] Re: Access COM interfaces, methods from whip.dll

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

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

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 │ ├──

[go-nuts] Access COM interfaces, methods from whip.dll

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

Re: [go-nuts] Debugging in Go 1.8

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

Re: [go-nuts] plugin questions....

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

Re: [go-nuts] Debugging in Go 1.8

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

[go-nuts] Investigating Go memory leaks

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

[go-nuts] Re: Can ServerMux serve two different handler functions on / and a path beyond / ?

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)

Re: [go-nuts] Regarding os.Stdout

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

Re: [go-nuts] Support for the race detector on ARM

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