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

[Dave Cheney]

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 Sunday, May 7, 2017 at 8:04:52 PM UTC-7, Dave Cheney wrote:
>>
>> The post over on stack overflow is confused. The behaviour of go test is 
>> to test multiple packages concurrently, inside a single package tests are 
>> executed serially by default. 
>
>

-- 
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: Are Go test methods run serially?

[st ov]

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 behaviour of go test is 
> to test multiple packages concurrently, inside a single package tests are 
> executed serially by default. 

-- 
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 float64 variable with value 0.0 as divisor produce +Inf?

[Michael Jones]

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 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 negation of x. The result of a floating-point or complex division by
> zero is not specified beyond the IEEE-754 standard; whether a run-time
> panic  occurs is
> implementation-specific.
>
> A const 0.0 divisor is illegal though:
>
> The divisor of a constant division or remainder operation must not be zero:
>
> 3.14 / 0.0   // illegal: division by zero
>
>
>
> On Tuesday, May 9, 2017 at 9:48:53 AM UTC+8, Michael Jones wrote:
>
>> 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 = 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 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.
>>>
>> --
>> Michael T. Jones
>> michae...@gmail.com
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Michael T. Jones
michael.jo...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Van Hu]

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 negation of x. The result of a floating-point or complex division by 
zero is not specified beyond the IEEE-754 standard; whether a run-time panic 
 occurs is 
implementation-specific.

A const 0.0 divisor is illegal though:

The divisor of a constant division or remainder operation must not be zero:

3.14 / 0.0   // illegal: division by zero



On Tuesday, May 9, 2017 at 9:48:53 AM UTC+8, Michael Jones wrote:
>
> 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 = 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 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.
>>
> -- 
> Michael T. Jones
> michae...@gmail.com 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Michael Jones]

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 = 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 from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Michael T. Jones
michael.jo...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Van Hu]

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 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: use of builtin print for debug

[Tong Sun]

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 curious why fmt.Printf doesn't work for you, though. In that case 
> you'd still probably want a way to turn off that specific output, but I'm 
> still curious.
>

Oh, nothing, just being lazy to have fewer thing to type. It started with 
two `print`s, then because the code is not working as I expected, so before 
I know, the prints are all over the places now -- unplanned. 

I thought I could easily wrap those `print`s into:

func debug(args ...interface{}) {
print(args...)
}

but only after doing that did I realize that I was wrong. 

-- 
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: Go 1.8.1 is released

[Dan Kortschak]

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 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: Delve v1.0.0-rc.1 release

[Derek Parker]

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 scris:
>>
>> 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, 
>> improvements and new features. I'll break down the new features shortly, 
>> but just wanted to call out this is an exciting milestone for the project, 
>> and we're excited to be driving towards a 1.0.0 release. What does that 
>> mean to you as a user? Well, not much should change, the project has been 
>> pretty stable, we have had API compatibility guarantees for a while now, 
>> etc, so this release is mostly symbolic. It does not mean the project is 
>> feature complete, we will be working hard to continue to add new features, 
>> support for more systems, and overall improvements as usual.
>>
>>  For a full list of changes, please check out the changelog 
>> ,
>>  
>> but I wanted to highlight some interesting features:
>>
>> Ability to swap low-level back ends. This means you can select either the 
>> native Delve back end, gdbserver, lldb-server, or Mozilla RR. The most 
>> exciting of this, in my opinion, is the ability to use the Mozilla RR (
>> http://rr-project.org/) project as a back end. This allows for record & 
>> replay deterministic debugging, and allows you to combine the power of 
>> Delve and RR into a very useful debugging tool for Go.
>>
>> Lastly, would just like to say thanks to the community overall for the 
>> support of the project and for all the patches, bug reports submitted 
>> editor integrations, etc, and co-maintainer Alessandro 
>>  for all the help, fixes, improvements, 
>> reviews and so on.
>>
>> Please check out this release, file bugs, and look out for the v1.0.0 
>> release within the coming weeks!
>>
>

-- 
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] use of builtin print for debug

['Kevin Malachowski' via golang-nuts]

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 way to turn off that specific output, but I'm still 
curious.

-- 
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: Delve v1.0.0-rc.1 release

[Gabriel Adumitrachioaiei]

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 
> 
> .
>
> This is a particularly big release for us, and includes a bunch of fixes, 
> improvements and new features. I'll break down the new features shortly, 
> but just wanted to call out this is an exciting milestone for the project, 
> and we're excited to be driving towards a 1.0.0 release. What does that 
> mean to you as a user? Well, not much should change, the project has been 
> pretty stable, we have had API compatibility guarantees for a while now, 
> etc, so this release is mostly symbolic. It does not mean the project is 
> feature complete, we will be working hard to continue to add new features, 
> support for more systems, and overall improvements as usual.
>
>  For a full list of changes, please check out the changelog 
> ,
>  
> but I wanted to highlight some interesting features:
>
> Ability to swap low-level back ends. This means you can select either the 
> native Delve back end, gdbserver, lldb-server, or Mozilla RR. The most 
> exciting of this, in my opinion, is the ability to use the Mozilla RR (
> http://rr-project.org/) project as a back end. This allows for record & 
> replay deterministic debugging, and allows you to combine the power of 
> Delve and RR into a very useful debugging tool for Go.
>
> Lastly, would just like to say thanks to the community overall for the 
> support of the project and for all the patches, bug reports submitted 
> editor integrations, etc, and co-maintainer Alessandro 
>  for all the help, fixes, improvements, 
> reviews and so on.
>
> Please check out this release, file bugs, and look out for the v1.0.0 
> release within the coming weeks!
>

-- 
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] use of builtin print for debug

[Tong Sun]

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 tried many ways, but seems 
commenting them off is the only way I can find. 

Please help. 

-- 
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] Do I need to unset variables in a for loop?

[Ian Lance Taylor]

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 golang do that for me? I "believe" in PHP a for loop keeps the
> variable in memory until the end of the script and if you want to remove the
> variable from memory you need to unset the variable to help conserve memory.

Go and PHP work very differently.  There is no need to unset a
variable in Go during a loop.  (I don't know if there is a need to do
so in PHP.)

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] Do I need to unset variables in a for loop?

[varcorb]

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 
variable in memory until the end of the script and if you want to remove 
the variable from memory you need to unset the variable to help conserve 
memory. 

-- 
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] Creating shared-libraries which override existing system functions?

[tonywalker . uk]

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 <: 
https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker-tricks-using-ld_preload-to-cheat-inject-features-and-investigate-programs/>
 where 
rand() is overridden.

If I write a simple function to overwrite it (see here 
) I get the following error when 
trying to compile with go build -o rand.so -buildmode=c-shared test.go (Go 
1.7.4 - same with 1.8 but a slightly different error):

# command-line-arguments
In file included from $WORK/command-line-arguments/_obj/_cgo_export.c:3:0:
/tmp/go-build613177413/command-line-arguments/_obj/_cgo_export.h:55:14: 
error: conflicting types for ‘rand’
 extern GoInt rand();
  ^~~~
In file included from $WORK/command-line-arguments/_obj/_cgo_export.c:2:0:
/usr/include/stdlib.h:335:12: note: previous declaration of ‘rand’ was here
 extern int rand (void) __THROW;
^~~~
/tmp/go-build613177413/command-line-arguments/_obj/_cgo_export.c:17:7: 
error: conflicting types for ‘rand’
 GoInt rand()
   ^~~~
In file included from $WORK/command-line-arguments/_obj/_cgo_export.c:2:0:
/usr/include/stdlib.h:335:12: note: previous declaration of ‘rand’ was here
 extern int rand (void) __THROW;
^~~~
I'm not clear whether I simply need to find a way to declare an equivalent 
signature which matches the stdlib, or whether creating a function which is 
already defined is just not allowed.

Can anyone help here?

Thanks,

Tony

-- 
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] Problem with Net UDP (ipv6) client socket

[Jean de Klerk]

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 and send/receive information to/from that server.
>
> Please see the below example. This seems to work even though I've 
> specified "udp" and not "udp6" (Both server and client address are local to 
> a network)
>
> package main
>
> import (
> "fmt"
> "net"
> )
>
> func CheckError(err error) {
> if err  != nil {
> fmt.Println("Error: " , err)
> }
> }
>
> func main() {
> ServerAddr,err := 
> net.ResolveUDPAddr("udp","[0:0:0:0:0::c0a8:cd36]:5400")
> CheckError(err)
>
> LocalAddr, err := net.ResolveUDPAddr("udp", 
> "[0:0:0:0:0::c0a8:130]:5400")
> CheckError(err)
>
> Conn, err := net.DialUDP("udp", LocalAddr, ServerAddr)
> CheckError(err)
>
> defer Conn.Close()
> }
>
> However, once I replace those "udp" strings with "udp6" as indicated in 
> the documentation, I get an error from the DialUDP() method "dial udp6 
> 192.168.1.48:5400->192.168.205.54:5400: bind: can't assign requested 
> address".
>
> For what it's worth, the code works if I replace those ipv6 strings with 
> their ipv4 strings and use "udp4" instead of "udp".
>
> Can someone explain why udp6 doesn't seem to work?
>
>
> Those are IPv4-mapped IPv6 addresses, which is to say regular IPv4 
> addresses expressed in IPv6 syntax for compatibility purposes. You are 
> using an IPv4 connection, which is why "udp" and "udp4" work but "udp6" 
> doesn't. 
>
> //jb
>
>

-- 
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] Possible optimization bug in go1.8?

[peterGo]

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, 2017 at 1:00:00 PM UTC-4, Ryan C. Decker wrote:
>
> 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...
>
>
>

-- 
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] Delve v1.0.0-rc.1 release

[Derek Parker]

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, 
improvements and new features. I'll break down the new features shortly, 
but just wanted to call out this is an exciting milestone for the project, 
and we're excited to be driving towards a 1.0.0 release. What does that 
mean to you as a user? Well, not much should change, the project has been 
pretty stable, we have had API compatibility guarantees for a while now, 
etc, so this release is mostly symbolic. It does not mean the project is 
feature complete, we will be working hard to continue to add new features, 
support for more systems, and overall improvements as usual.

 For a full list of changes, please check out the changelog 
,
 
but I wanted to highlight some interesting features:

Ability to swap low-level back ends. This means you can select either the 
native Delve back end, gdbserver, lldb-server, or Mozilla RR. The most 
exciting of this, in my opinion, is the ability to use the Mozilla RR 
(http://rr-project.org/) project as a back end. This allows for record & 
replay deterministic debugging, and allows you to combine the power of 
Delve and RR into a very useful debugging tool for Go.

Lastly, would just like to say thanks to the community overall for the 
support of the project and for all the patches, bug reports submitted 
editor integrations, etc, and co-maintainer Alessandro 
 for all the help, fixes, improvements, 
reviews and so on.

Please check out this release, file bugs, and look out for the v1.0.0 
release within the coming weeks!

-- 
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 received can be defined with/without pointer?

[Ian Lance Taylor]

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 not technically achievable.
> Just curious.


> if a new keyword appear to ensure a type is
> consumed by value, that might be helpful to provide
> a function to make sure that type won t exceed the stack size
> and escape to the heap.
> that keyword would help api designer to avoid consumption problems.
> nop ?

To me that seems like a very abstract concern.  The definition of the
method always makes it clear whether you are passing a value of the
type or a pointer to the type.  People defining methods on large types
should know which one want to use.  There is no need for an additional
keyword; the method definition is clear in any case.


> If a new keyword would appear to ensure a type is initialized by reference,
> might help to detect value copy and warn/error when that case is met.
> That would helped consumers to avoid problems.
> nop ?

Where would such a keyword be used?  The definition of the type makes
clear whether it has values or pointers.


> If the receiver type was not able to be star/nostar,
> that d probably help to get ride of confusion,
> nop ?

That would lose a clearly useful feature from the language.  In
particular, if you only permit pointer receivers or value receivers,
which one do you permit?  See also
https://golang.org/doc/faq#methods_on_values_or_pointers .

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] Possible optimization bug in go1.8?

[Decker, Ryan C.]

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
> 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 random number.
>>
>> See: 
>>
>> cheers
>> messju
>>
>>
>> On Mon, May 08, 2017 at 03:26:08AM -0700, sivarajshabin...@gmail.com
>> wrote:
>> >Hi All,
>> >
>> >Firstly, sorry for the title that sounds like a click bait. I am not
>> >understanding what exactly is wrong with this program
>> >[1]https://play.golang.org/p/Tl0wpaCqK7
>> >
>> >package main
>> >
>> >import  (
>> >"fmt"
>> >"math/rand"
>> >"runtime"
>> >)
>> >
>> >func xrand()  int  {
>> >r := rand.New(rand.NewSource(99))
>> >return r.Int()
>> >}
>> >
>> >func main()  {
>> >fmt.Printf("Version %s\n", runtime.Version())
>> >fmt.Printf("looks buggy \t1: %d, 2: %d, 3: %d\n", xrand(),
>> xrand(),
>> >xrand())
>> >
>> >r1 := rand.New(rand.NewSource(99))
>> >fmt.Printf("Looks fine  \t1: %d, 2: %d, 3: %d\n", r1.Int(),
>> >r1.Int(), r1.Int())
>> >}
>> >Output
>> >
>> >  Version go1.8
>> >  looks buggy 1: 1108929909, 2: 1108929909, 3: 1108929909
>> >  Looks find  1: 1108929909, 2: 1298032409, 3: 913431059
>> >
>> >When I generate a random number with "math/rand", like the example
>> given
>> >in documentation [2]https://play.golang.org/p/O2k_za0AW7 except
>> that I
>> >return the randomly generated integer from a function, But the
>> function
>> >keeps returning the same value any number of time I call it. On the
>> >contrary running the same code from the main generates random values,
>> >there isn't a reason to doubt rand package. However in the second
>> print
>> >statement where random numbers are properly generated the first value
>> >always is the same value returned by xrand(), here there is
>> something to
>> >doubt rand package.
>> >
>> >What am I missing here?  Could it be a bug?
>> >
>> >Thanks in advance.
>> >
>> >Cheers
>> >Shabinesh
>>
>> --
>> 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.
>>
>
>
>
> --
> Ryan C. Decker '08
> Sr. Network & Systems Engineer
> Siena College ITS
> 515 Loudon Road
> Loudonville, NY 12211
> rdec...@siena.edu
>
> CONFIDENTIALITY NOTICE: This e-mail, including any attachments, is for the
> sole use of the intended recipient(s) and may contain confidential and
> privileged information. Any unauthorized review, use, disclosure, or
> distribution is prohibited. If you received this e-mail and are not the
> intended recipient, please inform the sender by e-mail reply and destroy
> all copies of the original message.
>



-- 
Ryan C. Decker '08
Sr. Network & Systems Engineer
Siena College ITS
515 Loudon Road
Loudonville, NY 12211
rdec...@siena.edu

CONFIDENTIALITY NOTICE: This e-mail, including any attachments, is for the
sole use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure, or
distribution is prohibited. If you received this e-mail and are not the
intended recipient, please inform the sender by e-mail reply and destroy
all copies of the original message.

-- 
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] Possible optimization bug in go1.8?

[Decker, Ryan C.]

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 random number.
>
> See: 
>
> cheers
> messju
>
>
> On Mon, May 08, 2017 at 03:26:08AM -0700, sivarajshabin...@gmail.com
> wrote:
> >Hi All,
> >
> >Firstly, sorry for the title that sounds like a click bait. I am not
> >understanding what exactly is wrong with this program
> >[1]https://play.golang.org/p/Tl0wpaCqK7
> >
> >package main
> >
> >import  (
> >"fmt"
> >"math/rand"
> >"runtime"
> >)
> >
> >func xrand()  int  {
> >r := rand.New(rand.NewSource(99))
> >return r.Int()
> >}
> >
> >func main()  {
> >fmt.Printf("Version %s\n", runtime.Version())
> >fmt.Printf("looks buggy \t1: %d, 2: %d, 3: %d\n", xrand(),
> xrand(),
> >xrand())
> >
> >r1 := rand.New(rand.NewSource(99))
> >fmt.Printf("Looks fine  \t1: %d, 2: %d, 3: %d\n", r1.Int(),
> >r1.Int(), r1.Int())
> >}
> >Output
> >
> >  Version go1.8
> >  looks buggy 1: 1108929909, 2: 1108929909, 3: 1108929909
> >  Looks find  1: 1108929909, 2: 1298032409, 3: 913431059
> >
> >When I generate a random number with "math/rand", like the example
> given
> >in documentation [2]https://play.golang.org/p/O2k_za0AW7 except that
> I
> >return the randomly generated integer from a function, But the
> function
> >keeps returning the same value any number of time I call it. On the
> >contrary running the same code from the main generates random values,
> >there isn't a reason to doubt rand package. However in the second
> print
> >statement where random numbers are properly generated the first value
> >always is the same value returned by xrand(), here there is something
> to
> >doubt rand package.
> >
> >What am I missing here?  Could it be a bug?
> >
> >Thanks in advance.
> >
> >Cheers
> >Shabinesh
>
> --
> 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.
>



-- 
Ryan C. Decker '08
Sr. Network & Systems Engineer
Siena College ITS
515 Loudon Road
Loudonville, NY 12211
rdec...@siena.edu

CONFIDENTIALITY NOTICE: This e-mail, including any attachments, is for the
sole use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure, or
distribution is prohibited. If you received this e-mail and are not the
intended recipient, please inform the sender by e-mail reply and destroy
all copies of the original message.

-- 
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] Possible optimization bug in go1.8?

[shabinesh sivaraj]

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
> (determining the significance of this date is an exercise for the reader).
> This makes it easier to cache programs by giving them deterministic output.
> [...]"
>
>
> On Mon, May 08, 2017 at 10:22:14AM -0400, Decker, Ryan C. wrote:
> >See here: [1]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. <[2]
> rdec...@siena.edu>
> >wrote:
> >
> >  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
> >  <[3]mes...@lammfellpuschen.de> wrote:
> >
> >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: <[4]https://play.golang.org/p/XwNmYv5nzJ>
> >
> >cheers
> >messju
> >
> >On Mon, May 08, 2017 at 03:26:08AM -0700,
> >[5]sivarajshabin...@gmail.com wrote:
> >>Hi All,
> >>
> >>Firstly, sorry for the title that sounds like a click bait. I
> >am not
> >>understanding what exactly is wrong with this program
> >>[1][6]https://play.golang.org/p/Tl0wpaCqK7
> >>
> >>package main
> >>
> >>import  (
> >>"fmt"
> >>"math/rand"
> >>"runtime"
> >>)
> >>
> >>func xrand()  int  {
> >>r := rand.New(rand.NewSource(99))
> >>return r.Int()
> >>}
> >>
> >>func main()  {
> >>fmt.Printf("Version %s\n", runtime.Version())
> >>fmt.Printf("looks buggy \t1: %d, 2: %d, 3: %d\n",
> >xrand(), xrand(),
> >>xrand())
> >>
> >>r1 := rand.New(rand.NewSource(99))
> >>fmt.Printf("Looks fine  \t1: %d, 2: %d, 3: %d\n",
> >r1.Int(),
> >>r1.Int(), r1.Int())
> >>}
> >>Output
> >>
> >>  Version go1.8
> >>  looks buggy 1: 1108929909, 2: 1108929909, 3: 1108929909
> >>  Looks find  1: 1108929909, 2: 1298032409, 3: 913431059
> >>
> >>When I generate a random number with "math/rand", like the
> >example given
> >>in documentation [2][7]https://play.golang.org/p/O2k_za0AW7
> >except that I
> >>return the randomly generated integer from a function, But
> the
> >function
> >>keeps returning the same value any number of time I call it.
> On
> >the
> >>contrary running the same code from the main generates random
> >values,
> >>there isn't a reason to doubt rand package. However in the
> >second print
> >>statement where random numbers are properly generated the
> first
> >value
> >>always is the same value returned by xrand(), here there is
> >something to
> >>doubt rand package.
> >>
> >>What am I missing here?  Could it be a bug?
> >>
> >>Thanks in advance.
> >>
> >>Cheers
> >>Shabinesh
> >--
> >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 [8]golang-nuts+unsubscr...@googlegroups.com.
> >For more options, visit [9]https://groups.google.com/d/optout.
> >
> >  --
> >  Ryan C. Decker '08
> >  Sr. Network & Systems Engineer
> >  Siena College ITS
> >  515 Loudon Road
> >  Loudonville, NY 12211
> >  [10]rdec...@siena.edu
> >  CONFIDENTIALITY NOTICE: This e-mail, including any attachments, is
> for
> >  the sole use of the intended recipient(s) and may contain
> confidential
> >  and privileged information. Any unauthorized review, use,
> disclosure, or
> >  distribution is prohibited. If you received this e-mail and are not
> the
> >  intended recipient, please inform the sender by e-mail reply and
> destroy
> >  all copies of the original message.
> >
> >--
> >Ryan C. Decker '08
> >Sr. Network & Systems Engineer
> >Siena College ITS
> >515 Loudon Road
> >Loudonville, NY 12211
> >[11]rdec...@siena.edu
> >CONFIDENTIALITY NOTICE: This e-mail, including any attachments, is
> for the
> >sole use of the intended 

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

[messju mohr]

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 them deterministic output. [...]"


On Mon, May 08, 2017 at 10:22:14AM -0400, Decker, Ryan C. wrote:
>See here: [1]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. <[2]rdec...@siena.edu>
>wrote:
> 
>  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
>  <[3]mes...@lammfellpuschen.de> wrote:
> 
>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: <[4]https://play.golang.org/p/XwNmYv5nzJ>
> 
>cheers
>messju
> 
>On Mon, May 08, 2017 at 03:26:08AM -0700,
>[5]sivarajshabin...@gmail.com wrote:
>>    Hi All,
>>
>>    Firstly, sorry for the title that sounds like a click bait. I
>am not
>>    understanding what exactly is wrong with this program
>>    [1][6]https://play.golang.org/p/Tl0wpaCqK7
>>
>>    package main
>>
>>    import  (
>>        "fmt"
>>        "math/rand"
>>        "runtime"
>>    )
>>
>>    func xrand()  int  {
>>        r := rand.New(rand.NewSource(99))
>>        return r.Int()
>>    }
>>
>>    func main()  {
>>        fmt.Printf("Version %s\n", runtime.Version())
>>        fmt.Printf("looks buggy \t1: %d, 2: %d, 3: %d\n",
>xrand(), xrand(),
>>    xrand())
>>       
>>        r1 := rand.New(rand.NewSource(99))
>>        fmt.Printf("Looks fine  \t1: %d, 2: %d, 3: %d\n",
>r1.Int(),
>>    r1.Int(), r1.Int())
>>    }
>>    Output
>>
>>  Version go1.8
>>  looks buggy     1: 1108929909, 2: 1108929909, 3: 1108929909
>>  Looks find      1: 1108929909, 2: 1298032409, 3: 913431059
>>
>>    When I generate a random number with "math/rand", like the
>example given
>>    in documentation [2][7]https://play.golang.org/p/O2k_za0AW7
>except that I
>>    return the randomly generated integer from a function, But the
>function
>>    keeps returning the same value any number of time I call it. On
>the
>>    contrary running the same code from the main generates random
>values,
>>    there isn't a reason to doubt rand package. However in the
>second print
>>    statement where random numbers are properly generated the first
>value
>>    always is the same value returned by xrand(), here there is
>something to
>>    doubt rand package.
>>
>>    What am I missing here?  Could it be a bug?
>>
>>    Thanks in advance.
>>
>>    Cheers
>>    Shabinesh
>--
>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 [8]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [9]https://groups.google.com/d/optout.
> 
>  --
>  Ryan C. Decker '08
>  Sr. Network & Systems Engineer
>  Siena College ITS
>  515 Loudon Road
>  Loudonville, NY 12211
>  [10]rdec...@siena.edu
>  CONFIDENTIALITY NOTICE: This e-mail, including any attachments, is for
>  the sole use of the intended recipient(s) and may contain confidential
>  and privileged information. Any unauthorized review, use, disclosure, or
>  distribution is prohibited. If you received this e-mail and are not the
>  intended recipient, please inform the sender by e-mail reply and destroy
>  all copies of the original message.
> 
>--
>Ryan C. Decker '08
>Sr. Network & Systems Engineer
>Siena College ITS
>515 Loudon Road
>Loudonville, NY 12211
>[11]rdec...@siena.edu
>CONFIDENTIALITY NOTICE: This e-mail, including any attachments, is for the
>sole use of the intended recipient(s) and may contain confidential and
>privileged information. Any unauthorized review, use, disclosure, or
>distribution is prohibited. If you received this e-mail and are not the
>intended recipient, please inform the sender by e-mail reply and destroy
>all copies of the original message.
> 
> References
> 
>Visible links
>1. 

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

[Micky]

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 available without any restrictions :-(
>
> Yoshiyuki
>
> 2017/05/08 0:36、abbasnagh...@gmail.com:
>
> Why the Iranians have blocked?
> Is free and open source language golang?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[messju mohr]

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,
> 
>Firstly, sorry for the title that sounds like a click bait. I am not
>understanding what exactly is wrong with this program
>[1]https://play.golang.org/p/Tl0wpaCqK7
> 
>package main
> 
>import  (
>    "fmt"
>    "math/rand"
>    "runtime"
>)
> 
>func xrand()  int  {
>    r := rand.New(rand.NewSource(99))
>    return r.Int()
>}
> 
>func main()  {
>    fmt.Printf("Version %s\n", runtime.Version())
>    fmt.Printf("looks buggy \t1: %d, 2: %d, 3: %d\n", xrand(), xrand(),
>xrand())
>   
>    r1 := rand.New(rand.NewSource(99))
>    fmt.Printf("Looks fine  \t1: %d, 2: %d, 3: %d\n", r1.Int(),
>r1.Int(), r1.Int())
>}
>Output
> 
>  Version go1.8
>  looks buggy     1: 1108929909, 2: 1108929909, 3: 1108929909
>  Looks find      1: 1108929909, 2: 1298032409, 3: 913431059
> 
>When I generate a random number with "math/rand", like the example given
>in documentation [2]https://play.golang.org/p/O2k_za0AW7 except that I
>return the randomly generated integer from a function, But the function
>keeps returning the same value any number of time I call it. On the
>contrary running the same code from the main generates random values,
>there isn't a reason to doubt rand package. However in the second print
>statement where random numbers are properly generated the first value
>always is the same value returned by xrand(), here there is something to
>doubt rand package.
> 
>What am I missing here?  Could it be a bug?
> 
>Thanks in advance.
> 
>Cheers
>Shabinesh

-- 
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] Possible optimization bug in go1.8?

['chris dollin' via golang-nuts]

 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,   wrote:
> 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))
> return r.Int()
> }
>
> func main() {
> fmt.Printf("Version %s\n", runtime.Version())
> fmt.Printf("looks buggy \t1: %d, 2: %d, 3: %d\n", xrand(), xrand(),
> xrand())
>
> r1 := rand.New(rand.NewSource(99))
> fmt.Printf("Looks fine  \t1: %d, 2: %d, 3: %d\n", r1.Int(), r1.Int(),
> r1.Int())
> }
>
> Output
>
> Version go1.8
> looks buggy 1: 1108929909, 2: 1108929909, 3: 1108929909
> Looks find  1: 1108929909, 2: 1298032409, 3: 913431059
>
>
>
> When I generate a random number with "math/rand", like the example given in
> documentation https://play.golang.org/p/O2k_za0AW7 except that I return the
> randomly generated integer from a function, But the function keeps returning
> the same value any number of time I call it. On the contrary running the
> same code from the main generates random values, there isn't a reason to
> doubt rand package. However in the second print statement where random
> numbers are properly generated the first value always is the same value
> returned by xrand(), here there is something to doubt rand package.
>
> What am I missing here?  Could it be a bug?
>
> Thanks in advance.
>
> Cheers
> Shabinesh
>
> --
> 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.



-- 
Chris "allusive" Dollin

-- 
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] Possible optimization bug in go1.8?

[Jan Mercl]

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 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: Possible optimization bug in go1.8?

[Volker Dobler]

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 constant
value of 99 (roughly) and
r.Int()
reads one single number from this r. As r is _pseudo_ random
and has a constant state (seeded to 99) you always get the
same number.

V.

-- 
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] using GitHub Pages for import paths

['Jonathan Amsterdam' via golang-nuts]

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 the next year or two, as people split up multi-package repos in
order to version packages separately. If you use the repo URL directly as
an import path (e.g. "github.com/jba/gorepo/pkg1"), then splitting the repo
will change the import path.

To avoid changing the import path, you can use the import path redirection
 feature (a.k.a. vanity
paths). I can have import paths "jba.org/pkg1" and "jba.org/pkg2" both
point to "github.com/jba/gorepo" initially. If I later decide to have
separate repos for pkg1 and pkg2, I can keep the same import paths and just
change where they point. To use import path redirection, though, you need
both a domain and a server to host it. Many people already have that, but
if you don't it would be nice if there were a zero-effort way to get one.

I realized that GitHub Pages seems like a good choice for that. In case
you're not familiar, GitHub gives you a free static site for your username
or org (jba.github.io, in my case) that you have total control over, so you
can embed the necessary meta tag to make import path redirection work. The
URL is not ideal, but it's no worse than the raw repo URL. I'd guess the
availability of the site is the same or only a little less than the
availability of the repo itself. There are limits on the site, notably 100G
bandwidth/month, but unless you're hosting a lot of content or have a very
popular package, you're unlikely to hit that.

Does anyone already do this? Are there downsides that I'm missing?

-- 
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] Possible optimization bug in go1.8?

[sivarajshabinesh]

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))
return r.Int()
}

func main() {
fmt.Printf("Version %s\n", runtime.Version())
fmt.Printf("looks buggy \t1: %d, 2: %d, 3: %d\n", xrand(), xrand(), 
xrand())

r1 := rand.New(rand.NewSource(99))
fmt.Printf("Looks fine  \t1: %d, 2: %d, 3: %d\n", r1.Int(), r1.Int(), r1
.Int())
}

*Output*

Version go1.8
looks buggy 1: 1108929909, 2: 1108929909, 3: 1108929909
Looks find  1: 1108929909, 2: 1298032409, 3: 913431059



When I generate a random number with "math/rand", like the example given in 
documentation https://play.golang.org/p/O2k_za0AW7 
 except that I return the randomly 
generated integer from a function, But the function keeps returning the 
same value any number of time I call it. On the contrary running the same 
code from the main generates random values, there isn't a reason to doubt 
rand package. However in the second print statement where random numbers 
are properly generated the first value always is the same value returned by 
xrand(), here there is something to doubt rand package.

What am I missing here?  Could it be a bug?

Thanks in advance. 

Cheers
Shabinesh

-- 
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] Missing binary operator shortcuts &&= and ||=

[Michael Jones]

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 values and I was in fact counting
on each function being visited. I realized that && and || were my nemesis,
so I switched to integers, considering the lack of & and | for bool types a
loss for completeness and stayed away from bool since.

I don't know what I was thinking about the address-of-bool issue. I
remember it plainly but testing it just now I see that it works fine.
Hmm... Makes me feel old.

On Mon, May 8, 2017 at 12:45 AM, roger peppe  wrote:

> 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 have:
> >>>   EQUIVALENCE ("==")
> >>>   XOR ("!=")
> >>>   NOT ("!")  -- George Boole's NEGATION
> >>>
> >>> We lack:
> >>>   AND ("&") -- George Boole's CONJUNCTION
> >>>   OR ("|") -- George Boole's DISJUNCTION
> >>>
> >>> As it happens, one can implement all the operators from the basis of
> >>> NEGATION and either CONJUNCTION or DISJUNCTION, but as we lack each of
> the
> >>> last two, one must be sure to use ints where bools would be natural.
> >>
> >> I don't get it. What's the difference between a&
> >> and the hypothetical a for two expressions a and b,
> >> assuming a and b are free of side-effects ?
> >
> > There is none.
> >
> > But sometimes b has a side-effect.  And sometimes you want that
> > side-effect to be executed whether or not a is true.  Then writing `a
> > && b` does not work, and the alternatives are either verbose or
> > require introducing a new temporary variable name.
>
> If you're doing it a lot, then you could always do:
>
>   func and(x, y bool) bool { return x && y }
>
> 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.
>



-- 
Michael T. Jones
michael.jo...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Peter Mogensen]

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

--
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] Proper Way of Defining a Custom Context

[dc0d]

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 context? 
> > Is it enough to wrap the methods of parent `context.Context`? 
>
> I did some experiments trying to extend the context.Context interface. 
> One quickly runs into endless troubles due to the reliance on global 
> functions an the internal types of the context package. 
>
> /Peter 
>
>

-- 
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] Zero value of the map

[Will Faught]

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  > wrote:
>
> > Why couldn't maps be implemented as a pointer to the map implementation? 
> If you try to use the map and the pointer is nil, then the map allocates 
> the backing implementation. Pseudocode for a built-in implementation:
> >
> > type map struct {
> > impl *mapimpl
> > }
> > 
> > 
> > func (m map) set(k, v interface{}) { // used for m[k] = v
> > if m.impl == nil {
> > m.impl = newMapImpl()
> > }
> > m.impl.set(k, v)
> > }
>
> Without a pointer receiver the set method above is ineffective. With a 
> pointer receiver every map operation is double dereferencing.
>
> -- 
>
> -j
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[roger peppe]

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 have:
>>>   EQUIVALENCE ("==")
>>>   XOR ("!=")
>>>   NOT ("!")  -- George Boole's NEGATION
>>>
>>> We lack:
>>>   AND ("&") -- George Boole's CONJUNCTION
>>>   OR ("|") -- George Boole's DISJUNCTION
>>>
>>> As it happens, one can implement all the operators from the basis of
>>> NEGATION and either CONJUNCTION or DISJUNCTION, but as we lack each of the
>>> last two, one must be sure to use ints where bools would be natural.
>>
>> I don't get it. What's the difference between a&
>> and the hypothetical a for two expressions a and b,
>> assuming a and b are free of side-effects ?
>
> There is none.
>
> But sometimes b has a side-effect.  And sometimes you want that
> side-effect to be executed whether or not a is true.  Then writing `a
> && b` does not work, and the alternatives are either verbose or
> require introducing a new temporary variable name.

If you're doing it a lot, then you could always do:

  func and(x, y bool) bool { return x && y }

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.

-- 
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: Unexpected need to use runtime.KeepAlive().

['Keith Randall' via golang-nuts]

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
> }
>
> func NewIndexer() *Indexer {
>   i := {getCIndexerPointer()}
>   runtime.SetFinalizer(i, (*Indexer).finalize) 
> }
>
> func (i *Indexer) finalize() {
>   freeCIndexertPointer(i.cIndexer)
> }
>
> func (i *Indexer) Commit() {
>   callCCommit(i.cIndexer)
> }
>
> Then I have some code that uses an indexer object:
>
> func Index() {
>   i := NewIndexer()
>
>   // Index documents calling Indexer methods.
>
>   i.Commit()
> }
>
> For some corpus, the Commit() call above might take several minutes to 
> complete. It looks like that if the garbage collector kicks in when it is 
> running, the runtime thinks that it is ok to collect the object and this 
> triggers the finalizer that, in turn, deletes the internal C object that, 
> finally, make the C commit call to crash as the C struct it uses to do its 
> job was freed.
>
> I am aware that a call to runtime.KeepAlive(i) after the Commit() call 
> should be enough to sort this up, but I am wondering why it is required at 
> all in this case. Isn't the fact that a method on a struct type is running 
> enough to avoid collection?
>

No.  Method arguments are no different from regular arguments.  In your 
Commit method, i is not live after the call to callCCommit.  So as far as 
the live variable analysis is concerned, i is dead during the call.
 

> If not, shouldn't it be?
>

It used to be.  Before Go 1.7, we used to keep all arguments alive 
throughout the function.  It was kind of a hack, mostly to work around the 
lack of something like runtime.KeepAlive.  Keeping arguments live 
throughout the function often lead to objects being retained longer than 
necessary (the opposite problem from what you are observing).
We didn't see a way to solve this problem automatically.  We decided to use 
the minimal live ranges and provide runtime.KeepAlive so you can extend the 
live range.  I think the other direction (keeping the longer live ranges 
and providing a runtime.AssertThisIsDead) wouldn't work.
 

> Or is this related to the usage of CGO?
>
>
It often comes up in the context of CGO and finalizers, but this behavior 
can be observed in other contexts.
 

> In any case, it was a bit unexpected to me (although I did guess that the 
> problem was this and adding debug to the finalizer helped confirming it). I 
> would go as far as to say this looks like a bug.
>
> Thoughts?
>
>

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