Go 1.5 Beta 1 is released

Andrew Gerrand

unread,

Jul 8, 2015, 11:17:33 AM7/8/15

to golang-nuts

Hi Go nuts,

We have just released go1.5beta1, a beta version of Go 1.5.

It is cut from the master branch at the revision tagged go1.5beta1.

Please help us by testing your Go programs with the release, and report any problems using the issue tracker:

http://golang.org/issue/new

You can download binary and source distributions from the usual place:

http://golang.org/dl/#go1.5beta1

Note that we are not providing signed PKG or MSI installers for the beta.

(You can expect them for the release candidates and the final release.)

To find out what has changed in Go 1.5, read the release notes:

http://tip.golang.org/doc/go1.5

Documentation for Go 1.5 is available at:

http://tip.golang.org/

Our goal is to release the final version of Go 1.5 on December 1, 2014.

Andrew

Andrew Gerrand

unread,

Jul 8, 2015, 11:26:13 AM7/8/15

to golang-nuts

On 8 July 2015 at 09:16, Andrew Gerrand <a...@golang.org> wrote:

Our goal is to release the final version of Go 1.5 on December 1, 2014.

And, it being impossible to do the release in the past, we'll aim to release it on August 1, 2015.

andrewc...@gmail.com

unread,

Jul 8, 2015, 7:17:54 PM7/8/15

to golan...@googlegroups.com

The command line go doc command rocks. I think the new GC and changes allowing GOMAXPROCS to use more cores by default are a great milestone.

Thanks Go Team.

Micky

unread,

Jul 8, 2015, 8:41:04 PM7/8/15

to Andrew Gerrand, golang-nuts

Super exciting.

But isn't one month of beta testing not enough?

andrewc...@gmail.com

unread,

Jul 8, 2015, 8:45:03 PM7/8/15

to golan...@googlegroups.com, a...@golang.org

>But isn't one month of beta testing not enough?

They actually entered a code freeze a while ago, and I think many people test with the git version as it comes along.

Andrew Gerrand

unread,

Jul 9, 2015, 11:00:32 AM7/9/15

to Micky, golang-nuts

On 8 July 2015 at 18:40, Micky <mickyl...@gmail.com> wrote:

But isn't one month of beta testing not enough?

I think it depends on the kinds of bugs that surface.

If we have a very quiet beta, with few bugs, then one month is ample time.

If there are serious issues that require subsequent beta releases, we might have to push the release back.

Andrew

gony...@gmail.com

unread,

Jul 9, 2015, 4:54:22 PM7/9/15

to golan...@googlegroups.com

Hi guys,

I ran small test (loading big data into memory and processing)

And I used debug.FreeOSMemory() to clear memory after using those data.

I ran 2 test each for 1.4 compiler and 1.5b1 compiler.

In 1.4, whenever I call FreeOSMemory, the allocated memory went down.

However with 1.5, it seems like debug.FreeOSMemory doesn't do anything.

Is there some change I need to make?

Thank you

with 1.4 compiler

[ INFO ] 15:27:16 Job started

[ INFO ] 15:27:16 Input file process started

[ INFO ] 15:28:11 2,005,289 records loaded

[ INFO ] 15:28:11 Memory allocated: 7129.02 MB

[ INFO ] 15:28:11 Cleaning memory

[ INFO ] 15:28:29 Memory usage after cleaning: 6175.7MB

[ INFO ] 15:28:30 Detail calculation finished for requirement 4vi

[ INFO ] 15:28:31 Detail calculation finished for requirement 4vii

[ INFO ] 15:28:32 Detail calculation finished for requirement 4v

[ INFO ] 15:28:34 Detail calculation finished for requirement 4ii & 4ii-a

[ INFO ] 15:28:34 All detail calculation finished

[ INFO ] 15:28:34 Memory allocated: 6180.92 MB

[ INFO ] 15:28:34 Cleaning memory

[ INFO ] 15:28:51 Memory allocated: 5677.43 MB

[ INFO ] 15:28:51 Printing reports started

[ INFO ] 15:28:51 Writing files

[ INFO ] 15:28:52 Cleaning memory

[ INFO ] 15:28:53 Memory allocated: 0.05 MB

[ INFO ] 15:28:53 Job finished

with 1.5 compiler

[ INFO ] 15:29:04 Job started

[ INFO ] 15:29:04 Input file process started

[ INFO ] 15:30:11 2,005,289 records loaded

[ INFO ] 15:30:11 Memory allocated: 6861.63 MB

[ INFO ] 15:30:11 Cleaning memory

[ INFO ] 15:30:21 Memory usage after cleaning: 6175.7MB

[ INFO ] 15:30:22 Detail calculation finished for requirement 4vi

[ INFO ] 15:30:23 Detail calculation finished for requirement 4vii

[ INFO ] 15:30:23 Detail calculation finished for requirement 4v

[ INFO ] 15:30:25 Detail calculation finished for requirement 4ii & 4ii-a

[ INFO ] 15:30:25 All detail calculation finished

[ INFO ] 15:30:26 Memory allocated: 6259.62 MB

[ INFO ] 15:30:26 Cleaning memory

[ INFO ] 15:30:35 Memory allocated: 6175.69 MB

[ INFO ] 15:30:35 Printing reports started

[ INFO ] 15:30:35 Writing files

[ INFO ] 15:30:36 Cleaning memory

[ INFO ] 15:30:46 Memory allocated: 6175.69 MB

[ INFO ] 15:30:46 Job finished

alex25...@gmail.com

unread,

Jul 10, 2015, 6:50:19 AM7/10/15

to golan...@googlegroups.com

https://github.com/bradfitz/http2 won't be add in this release? Or I missed something?

hemant.c...@gmail.com

unread,

Jul 10, 2015, 9:27:22 AM7/10/15

to golan...@googlegroups.com

I am using windows 64 version and when i compile my code i get following error:

c:\go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1

c:/mingw/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mi

ngw32/bin/ld.exe: cannot find -lRFA_x64

collect2.exe: error: ld returned 1 exit status

Hemant

Michel Casabianca

unread,

Jul 10, 2015, 9:27:26 AM7/10/15

to golan...@googlegroups.com

Please help us by testing your Go programs with the release, and report any problems using the issue tracker:
http://golang.org/issue/new

Go 1.5 builds one of my projects (https://github.com/c4s4/changelog) 10 times slower. I build binaries for all Go supported platforms. Is cross-compilation significantly slower ?

Ian Lance Taylor

unread,

Jul 10, 2015, 9:34:45 AM7/10/15

to Michel Casabianca, golang-nuts

Cross compilation is not slower than native compilation.

However, the compiler is, unfortunately, somewhat slower in 1.5. We
are going to work hard to speed it up in 1.6. But 1.5 is not, in our
measurements, 10 times slower--it's not even twice as slow for most
builds. I don't know why you are seeing such a slowdown. You may be
hitting a particularly bad case for some reason. I would encourage
you to investigate what specifically is slow, and open an issue if you
find anything interesting.

Ian

Nathan Youngman

unread,

Jul 10, 2015, 11:35:45 AM7/10/15

to golan...@googlegroups.com, alex25...@gmail.com

From what I've heard, HTTP/2 will hopefully be included in Go 1.6.

Until then, you can use bradfitz/http2 for an H2 (HTTP/2) server.

Nathan.

Brad Fitzpatrick

unread,

Jul 10, 2015, 3:10:19 PM7/10/15

to alex25...@gmail.com, golang-nuts

On Fri, Jul 10, 2015 at 3:22 AM, <alex25...@gmail.com> wrote:

https://github.com/bradfitz/http2 won't be add in this release? Or I missed something?

No, not until Go 1.6.

Like Nathan said, you can use https://github.com/bradfitz/http2 for now, but parts aren't done yet.

Nick Craig-Wood

unread,

Jul 10, 2015, 5:53:19 PM7/10/15

to golang-nuts

Now for some good news...

In my project (a compiler/interpreter/vm) which uses lots and lots of
interfaces and generates astounding amounts of garbage, when I compile
it with go 1.5 beta it runs 20-25% faster than go 1.4.

I can see the CPU usage going above 100% in this single threaded program
which means the concurrent garbage collector is working well.

Well done the Go team!

--
Nick Craig-Wood <ni...@craig-wood.com> -- http://www.craig-wood.com/nick

Frank Schröder

unread,

Jul 13, 2015, 11:14:56 AM7/13/15

to golan...@googlegroups.com

I'm seeing 2x slower compilation times with Go 1.5

https://groups.google.com/forum/#!searchin/golang-nuts/1.5/golang-nuts/uBFzGIturOA/o8wEGaT54b4J

Frank

Andrew Watson

unread,

Jul 13, 2015, 2:56:34 PM7/13/15

to golan...@googlegroups.com

Also, there is a 1.5beta1 tag for the library/golang docker image as well.

https://registry.hub.docker.com/_/golang/

"docker pull library/golang:1.5beta1"

ricardo...@mega.com.br

unread,

Jul 13, 2015, 5:40:54 PM7/13/15

to golan...@googlegroups.com

Hello, and great job!

I downloaded it to test, however I'm getting problems connecting to Oracle database on Windows 64. Both go-oci8 and goracle return the same error, which I pasted below. Is this the proper place to report it?

I also tested on Ubuntu 15.04 64 bits and it works great, doesn't show any errors and my application is 30+% faster.

go-oci8:

Exception 0xc0000005 0x8 0x0 0x0
PC=0x0
signal arrived during external code execution

github.com/mattn/go-oci8._Cfunc_WrapOCIEnvCreate(0x1, 0x0, 0x0, 0x0, 0x0)
        ??:0 +0x5a
github.com/mattn/go-oci8.(*OCI8Driver).Open(0x6de698, 0x5f4d70, 0x11, 0x0, 0x0, 0x0, 0x0)
        C:/Projetos/Go/src/github.com/mattn/go-oci8/oci8.go:531 +0x4a8
database/sql.(*DB).conn(0xc08206a140, 0x1, 0x10, 0x0, 0x0)
        c:/go/src/database/sql/sql.go:710 +0x458
database/sql.(*DB).query(0xc08206a140, 0x61c760, 0xcc, 0x0, 0x0, 0x0, 0xc081ffd701, 0x0, 0x0, 0x0)
        c:/go/src/database/sql/sql.go:957 +0x4d
database/sql.(*DB).Query(0xc08206a140, 0x61c760, 0xcc, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        c:/go/src/database/sql/sql.go:945 +0xaa
main.executaRegistro(0x1, 0xc08205fea8, 0x0)
        C:/projetos/go/exemplos-Go/oracle.go:44 +0x167
main.executa()
        C:/projetos/go/exemplos-Go/oracle.go:92 +0x38a
main.main()
        C:/projetos/go/exemplos-Go/oracle.go:28 +0x4d

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        c:/go/src/runtime/asm_amd64.s:1696 +0x1

goroutine 5 [chan receive]:
database/sql.(*DB).connectionOpener(0xc08206a140)
        c:/go/src/database/sql/sql.go:634 +0x4c
created by database/sql.Open
        c:/go/src/database/sql/sql.go:481 +0x33d
rax     0x22fd30
rbx     0xc08205f680
rcx     0x22fd30
rdi     0xc08205f680
rsi     0x6bb200
rbp     0x22fd50
rsp     0x22fce8
r8      0x0
r9      0x0
r10     0xc082008de0
r11     0x55555555555555
r12     0x3
r13     0x61a762
r14     0x38
r15     0x0
rip     0x0
rflags  0x10246
cs      0x33
fs      0x53
gs      0x2b
exit status 2

goracle:

Exception 0xc0000005 0x8 0x0 0x0
PC=0x0
signal arrived during external code execution

gopkg.in/goracle.v1/oracle._Cfunc_OCIEnvNlsCreate(0xc082052c60, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        ??:0 +0x43
gopkg.in/goracle.v1/oracle.NewEnvironment(0x662d20, 0x0, 0x0)
        C:/Projetos/Go/src/gopkg.in/goracle.v1/oracle/environment.go:99 +0x266
gopkg.in/goracle.v1/oracle.NewConnection(0xc082008ee0, 0x6, 0xc082008ee7, 0x4, 0xc082008eec, 0x5, 0xc082008e00, 0xc08200
e380, 0x0, 0x0)
        C:/Projetos/Go/src/gopkg.in/goracle.v1/oracle/connection.go:132 +0xd1
gopkg.in/goracle%2ev1.(*Driver).Open(0x7b20a0, 0xc082008ee0, 0x11, 0x0, 0x0, 0x0, 0x0)
        C:/Projetos/Go/src/gopkg.in/goracle.v1/driver.go:255 +0x166
database/sql.(*DB).conn(0xc08206a140, 0x472501, 0xc082039040, 0x0, 0x0)
        c:/go/src/database/sql/sql.go:710 +0x458
database/sql.(*DB).begin(0xc08206a140, 0xc08205fe01, 0x1, 0x0, 0x0)
        c:/go/src/database/sql/sql.go:1048 +0x46
database/sql.(*DB).Begin(0xc08206a140, 0x1, 0x0, 0x0)
        c:/go/src/database/sql/sql.go:1036 +0x63
main.executa()
        C:/projetos/go/exemplos-Go/goracle.go:27 +0x2b9
main.main()
        C:/projetos/go/exemplos-Go/goracle.go:14 +0x4d

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        c:/go/src/runtime/asm_amd64.s:1696 +0x1

goroutine 5 [chan receive]:
database/sql.(*DB).connectionOpener(0xc08206a140)
        c:/go/src/database/sql/sql.go:634 +0x4c
created by database/sql.Open
        c:/go/src/database/sql/sql.go:481 +0x33d
rax     0xc082052c60
rbx     0x0
rcx     0xc082052c60
rdi     0x0
rsi     0x0
rbp     0x22fda0
rsp     0x22fd18
r8      0x0
r9      0x0
r10     0x0
r11     0x0
r12     0x10
r13     0x6e231c
r14     0x8
r15     0x0
rip     0x0
rflags  0x10202
cs      0x33
fs      0x53
gs      0x2b
exit status 2

gerald...@gmail.com

unread,

Jul 14, 2015, 3:30:59 AM7/14/15

to golan...@googlegroups.com, ricardo...@mega.com.br

i guess you can open a new issue + add a testcase to reproduce the issue: https://github.com/golang/go/issues

Tarmigan

unread,

Jul 16, 2015, 3:48:08 AM7/16/15

to Brad Fitzpatrick, Rob Pike, golang-nuts

We have an http test that passes with go1.4 but fails with go1.5beta1.

Our http handler has an explicit check against content length too long:

if r.ContentLength >= contentLengthLimit {
w.WriteHeader(http.StatusBadRequest)
return
}

Our tests check for the 400 code back, but now the test returns an error instead getting a response back:

req, _ := http.NewRequest(method, url, strings.NewReader(contents))
client := &http.Client{}
resp, err := client.Do(req)
if err != nil {
t.Fatal(err)
}

In go1.4 client.Do() would return with err==nil, but in go1.5beta1 the error comes back "Put http://localhost:8080/debug/test_program.json: write tcp 127.0.0.1:53000->127.0.0.1:8080: write: connection reset by peer"

This appears to be the intended behavior after https://github.com/golang/go/commit/1045351cef21a64d954b4477af9f5105ea4287d3

I don't necessarily think this is a regression, but still might be worth mentioning in the release notes.

Thanks,
Tarmigan

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

Brad Fitzpatrick

unread,

Jul 16, 2015, 4:26:33 PM7/16/15

to Tarmigan, Rob Pike, golang-nuts

Can you file a bug with more details for me to track?

Problems like this have come up in the past. What's probably happening is that the server is replying with the 400 from your handler, and it's being sent on the wire fine, but then the Go HTTP client (client.Do) is reporting the request body copy error before the response. We could adjust how we tear down connections in this case on the server (do a CloseWrite instead of a Close, and do the full TCP close on a timer), and maybe adjust the client more somehow... return both the response header and the error? Or maybe return a structured error with the response header seen in the error type?

This sort of HTTP race never seems to go away.

Tarmigan

unread,

Jul 16, 2015, 11:18:20 PM7/16/15

to Brad Fitzpatrick, Rob Pike, golang-nuts

I agree that the correct response is not obvious in this case. Ticket is http://golang.org/issue/11745