[go-nuts] Re: Are Go test methods run serially?

That is correct. See the -p flag in `go help build` On Tuesday, 9 May 2017 14:52:18 UTC+10, st ov wrote: > > Thanks yet again for clarifying and correcting my assumptions. > So within a single package tests are run serially, but I can't rely on > that when testing multiple packages. > > > > On

[go-nuts] Re: Are Go test methods run serially?

Thanks yet again for clarifying and correcting my assumptions. So within a single package tests are run serially, but I can't rely on that when testing multiple packages. On Sunday, May 7, 2017 at 8:04:52 PM UTC-7, Dave Cheney wrote: > > The post over on stack overflow is confused. The

Re: [go-nuts] Why float64 variable with value 0.0 as divisor produce +Inf?

Why doesn't division by zero (or overflow, or underflow) stop the program or trigger an error? http://grouper.ieee.org/groups/754/faq.html On Mon, May 8, 2017 at 6:57 PM Van Hu wrote: > Usually I would expect a panic just as Go does with integer, but I just > found this

Re: [go-nuts] Why float64 variable with value 0.0 as divisor produce +Inf?

Usually I would expect a panic just as Go does with integer, but I just found this from the Golang spec. It's new information to me that float-point 0 as divisor isn't specified by standard. Floating-point operators For floating-point and complex numbers, +x is the same as x, while -x is the

Re: [go-nuts] Why float64 variable with value 0.0 as divisor produce +Inf?

This is the definition of that division. What result would you prefer? On Mon, May 8, 2017 at 6:45 PM Van Hu wrote: > Hi, my colleague found this strange behavior in Go today, seems like a bug? > > package main > > import ( > "fmt" > ) > > func main() { > var a float64 =

[go-nuts] Why float64 variable with value 0.0 as divisor produce +Inf?

Hi, my colleague found this strange behavior in Go today, seems like a bug? package main import ( "fmt" ) func main() { var a float64 = 0.0 fmt.Println(1.0 / a) // prints +Inf } -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe

[go-nuts] Re: use of builtin print for debug

On Monday, May 8, 2017 at 8:28:45 PM UTC-4, Kevin Malachowski wrote: > > You can declare a func "print" in each package which just calls the real > print func. When you want to turn off printing, you just have one line to > comment out in that func to affect all callers. Thanks > I'm

Re: [go-nuts] Re: Go 1.8.1 is released

Is github not visible from there? If it is, clone the repos from github to the expected locations for $GOPATH and $GOROOT. On Mon, 2017-05-08 at 19:39 +0500, Micky wrote: > It's just politics! > > Simply use a VPN, Tor or a proxy to bypass the filter! -- You received this message because you

[go-nuts] Re: Delve v1.0.0-rc.1 release

It _will_ be... eventually :). But not in this release unfortunately. On Monday, May 8, 2017 at 5:23:32 PM UTC-7, Gabriel Adumitrachioaiei wrote: > > Will it be possible to do function calls: > https://github.com/derekparker/delve/issues/119 > > > luni, 8 mai 2017, 19:42:43 UTC+1, Derek Parker a

[go-nuts] use of builtin print for debug

You can declare a func "print" in each package which just calls the real print func. When you want to turn off printing, you just have one line to comment out in that func to affect all callers. I'm curious why fmt.Printf doesn't work for you, though. In that case you'd still probably want a

[go-nuts] Re: Delve v1.0.0-rc.1 release

Will it be possible to do function calls: https://github.com/derekparker/delve/issues/119 luni, 8 mai 2017, 19:42:43 UTC+1, Derek Parker a scris: > > Hey all, > > Just wanted to make some noise about the latest Delve > release, v1.0.0-rc.1 >

[go-nuts] use of builtin print for debug

I know using of builtin print is not encouraged, but it's convenient, and I've sprinted it all over my code. Now debugging is over, I need to disable all the builtin prints. Is there any easy way to toggle the printing on and off, so that I can enable debugging any time in the future? I've

Re: [go-nuts] Do I need to unset variables in a for loop?

On Mon, May 8, 2017 at 3:09 PM, wrote: > > I have heard that golang has excellent memory management / garbage > collection. If I am preforming millions of calculations in a for loop do I > need to unset a variable before the end of the for loop to help with memory > or does

[go-nuts] Do I need to unset variables in a for loop?

I have heard that golang has excellent memory management / garbage collection. If I am preforming millions of calculations in a for loop do I need to unset a variable before the end of the for loop to help with memory or does golang do that for me? I "believe" in PHP a for loop keeps the

[go-nuts] Creating shared-libraries which override existing system functions?

Hi All, I'd like to experiment writing a shared library that will override system functions via LD_LIBRARY_PATH. I'd like to achieve something like the basic functionality demonstrated here <:

Re: [go-nuts] Problem with Net UDP (ipv6) client socket

Has there been resolution on this? I get this error now and then, too. On Tuesday, August 2, 2016 at 12:25:09 PM UTC-6, Jakob Borg wrote: > > > On 2 aug. 2016, at 15:19, CN47 wrote: > > I'm working on an API that should connect via IPv4 and Ipv6 to a server > via UDP packets

Re: [go-nuts] Possible optimization bug in go1.8?

Ryan, It's not weird. https://play.golang.org -> About In the playground the time begins at 2009-11-10 23:00:00 UTC (determining the significance of this date is an exercise for the reader). This makes it easier to cache programs by giving them deterministic output. Peter On Monday, May 8,

[go-nuts] Delve v1.0.0-rc.1 release

Hey all, Just wanted to make some noise about the latest Delve release, v1.0.0-rc.1 . This is a particularly big release for us, and includes a bunch of fixes,

Re: [go-nuts] why received can be defined with/without pointer?

On Sun, May 7, 2017 at 3:37 AM, wrote: > yes, sorry you scratched your head > > https://play.golang.org/p/Gg6Euyvsw6 > > this example shows that it is possible to do all the things. > hth. > > I m curious to know more about other questions. > Maybe they are not good idea, or

Re: [go-nuts] Possible optimization bug in go1.8?

See here: https://play.golang.org/p/EjdQRUnwQF The weird thing is that time.Now().UnixNano() doesn't appear to ever change in the playground... On Mon, May 8, 2017 at 10:21 AM, Decker, Ryan C. wrote: > I usually follow the example and go with time.Now().UnixNano() which you

Re: [go-nuts] Possible optimization bug in go1.8?

I usually follow the example and go with time.Now().UnixNano() which you can see here: On Mon, May 8, 2017 at 10:07 AM, messju mohr wrote: > Hi, > > in xrand() you are initialising r with the same constant seed for > every call, so you always get the same pseudo

Re: [go-nuts] Possible optimization bug in go1.8?

Thank you all for replying. I get it now. On 8 May 2017 8:20 pm, "messju mohr" wrote: > > It's not strange, it's intended behaviour of the playground. See the > "about" page of the playground: > "[...] In the playground the time begins at 2009-11-10 23:00:00 UTC >

Re: [go-nuts] Possible optimization bug in go1.8?

It's not strange, it's intended behaviour of the playground. See the "about" page of the playground: "[...] In the playground the time begins at 2009-11-10 23:00:00 UTC (determining the significance of this date is an exercise for the reader). This makes it easier to cache programs by giving

Re: [go-nuts] Re: Go 1.8.1 is released

It's just politics! Simply use a VPN, Tor or a proxy to bypass the filter! On Sun, May 7, 2017 at 8:59 PM, ahochauwa wrote: > Hello, > > This issue might help you understand why: > https://github.com/golang/go/issues/12380 > > I hope one day Golang would be

Re: [go-nuts] Possible optimization bug in go1.8?

Hi, in xrand() you are initialising r with the same constant seed for every call, so you always get the same pseudo random number. See: cheers messju On Mon, May 08, 2017 at 03:26:08AM -0700, sivarajshabin...@gmail.com wrote: >Hi All, > >

Re: [go-nuts] Possible optimization bug in go1.8?

Every call of xrand calls .Int() on a fresh generator initialised the same way as the previous one, so it will give the same result. The calls to .Int() in main are all on the /same/ generator, which is updated by each call, so you get three different values. Chris On 8 May 2017 at 11:26,

Re: [go-nuts] Possible optimization bug in go1.8?

On Mon, May 8, 2017 at 3:50 PM wrote: > Could it be a bug? No, the xrand function will always return the same number. -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

[go-nuts] Re: Possible optimization bug in go1.8?

On Monday, 8 May 2017 15:51:00 UTC+2, Shabinesh Sivaraj wrote: > > func xrand() int { > r := rand.New(rand.NewSource(99)) > return r.Int() > } > What am I missing here? Could it be a bug? > Not a bug. r := rand.New(rand.NewSource(99)) creates a new random number generator seeded to a

[go-nuts] using GitHub Pages for import paths

What do you all think about using GitHub Pages URLs for import paths? I got to thinking about that because Go is moving towards having real dependency management, and it looks like the repo is going to be the unit of versioning. That implies that repo boundaries are going to be changing a lot in

[go-nuts] Possible optimization bug in go1.8?

Hi All, Firstly, sorry for the title that sounds like a click bait. I am not understanding what exactly is wrong with this program https://play.golang.org/p/Tl0wpaCqK7 package main import ( "fmt" "math/rand" "runtime" ) func xrand() int { r := rand.New(rand.NewSource(99))

Re: [go-nuts] Missing binary operator shortcuts &&= and ||=

To be honest, I generally think that having two sub-expressions with visible side-effects in the same expression is not great practice, even if Go does guarantee order of evaluation. ...in my case, I had an expression rewrite system (think DeMorgan’s theorems) with boolean functions for the

Re: [go-nuts] Proper Way of Defining a Custom Context

On 2017-05-08 11:55, dc0d wrote: So just Value(...) then? Of-course I've implemented an adapter with no extra fields, just with some methods to work with Value(...). Yeah...that would be my best advice - unless someone else can demonstrate a clean way to extend context.Context. /Peter

Re: [go-nuts] Proper Way of Defining a Custom Context

So just Value(...) then? Of-course I've implemented an adapter with no extra fields, just with some methods to work with Value(...). On Sunday, May 7, 2017 at 2:41:31 PM UTC+4:30, Peter Mogensen wrote: > > > > On 2017-05-07 11:58, dc0d wrote: > > What's the proper way of defining a custom

Re: [go-nuts] Zero value of the map

Yes, you're right, the receiver should be a pointer. What's bad about a double pointer dereference? Isn't that what, say, bytes.Buffer does, more or less, at least conceptually? On Thursday, April 20, 2017 at 1:22:56 AM UTC-7, Jan Mercl wrote: > > On Thu, Apr 20, 2017 at 9:42 AM Will Faught

Re: [go-nuts] Missing binary operator shortcuts &&= and ||=

On 7 May 2017 at 02:00, Ian Lance Taylor wrote: > On Fri, May 5, 2017 at 10:26 AM, roger peppe wrote: >> On 5 May 2017 at 14:11, Michael Jones wrote: >>> Just so. One cannot do boolean arithmetic with boolean variables. >>> >>> We

[go-nuts] Re: Unexpected need to use runtime.KeepAlive().

On Sunday, May 7, 2017 at 8:21:38 AM UTC-7, Bruno Albuquerque wrote: > > I have this struct that has an associated method that simply call a C > function that might take a long time to use. It is defined more or less > like this: > > import "C" > > type Indexer struct { > cIndexer *C.Indexer