Go 1.5 Beta 1 is released

[Andrew Gerrand]

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]

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]

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]

Super exciting.

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

[andrewc...@gmail.com]

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

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]

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]

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

[hemant.c...@gmail.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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Tarmigan]

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]

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]

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

Thanks,

Tarmigan