[go-nuts] Go 1.5 Beta 1 is released

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

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.

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

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

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

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

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.

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.

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

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 ?

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

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!

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

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"

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

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

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

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.

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

Thanks,
Tarmigan