| Go 1.5 Beta 1 is released | Andrew Gerrand | 08/07/15 08:17 | 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: You can download binary and source distributions from the usual place: 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: Documentation for Go 1.5 is available at: Our goal is to release the final version of Go 1.5 on December 1, 2014. Andrew |
| Re: Go 1.5 Beta 1 is released | Andrew Gerrand | 08/07/15 08:26 | On 8 July 2015 at 09:16, Andrew Gerrand <a...@golang.org> wrote: And, it being impossible to do the release in the past, we'll aim to release it on August 1, 2015. |
| Re: Go 1.5 Beta 1 is released | Andrew Chambers | 08/07/15 16:17 | 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. |
| Re: [go-nuts] Re: Go 1.5 Beta 1 is released | Micky | 08/07/15 17:41 | Super exciting. But isn't one month of beta testing not enough? |
| Re: [go-nuts] Re: Go 1.5 Beta 1 is released | Andrew Chambers | 08/07/15 17:45 | >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. |
| Re: [go-nuts] Re: Go 1.5 Beta 1 is released | Andrew Gerrand | 09/07/15 08:00 | 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 |
| Re: Go 1.5 Beta 1 is released | Gon Yi | 09/07/15 13:54 | 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 |
| Re: Go 1.5 Beta 1 is released | Гордон Алекс | 10/07/15 03:50 | https://github.com/bradfitz/http2 won't be add in this release? Or I missed something? |
| Re: Go 1.5 Beta 1 is released | Hemant Kumar Chitodiya | 10/07/15 06:27 | 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 |
| Re: Go 1.5 Beta 1 is released | Michel Casabianca | 10/07/15 06:27 |
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 ? |
| Re: [go-nuts] Re: Go 1.5 Beta 1 is released | Ian Lance Taylor | 10/07/15 06:34 | 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 |
| Re: Go 1.5 Beta 1 is released | Nathan Youngman | 10/07/15 08:35 | Until then, you can use bradfitz/http2 for an H2 (HTTP/2) server. Nathan. |
| Re: [go-nuts] Re: Go 1.5 Beta 1 is released | bradfitz | 10/07/15 12:10 | On Fri, Jul 10, 2015 at 3:22 AM, <alex25...@gmail.com> wrote: 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. |
| Re: [go-nuts] Re: Go 1.5 Beta 1 is released | Nick Craig-Wood | 10/07/15 14:53 | 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 |
| Re: Go 1.5 Beta 1 is released | Frank Schröder | 13/07/15 08:14 | I'm seeing 2x slower compilation times with Go 1.5 Frank |
| Re: Go 1.5 Beta 1 is released | Andrew Watson | 13/07/15 11:56 | Also, there is a 1.5beta1 tag for the library/golang docker image as well. "docker pull library/golang:1.5beta1" |
| Re: Go 1.5 Beta 1 is released | ricardo...@mega.com.br | 13/07/15 14:40 | 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: goracle: |
| Re: Go 1.5 Beta 1 is released | Gerald Stan | 14/07/15 00:30 | i guess you can open a new issue + add a testcase to reproduce the issue: https://github.com/golang/go/issues |
| Re: [go-nuts] Go 1.5 Beta 1 is released | Tarmigan | 16/07/15 00:48 | 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 -- |
| Re: [go-nuts] Go 1.5 Beta 1 is released | bradfitz | 16/07/15 13:26 | 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. |
| Re: [go-nuts] Go 1.5 Beta 1 is released | Tarmigan | 16/07/15 20:18 | I agree that the correct response is not obvious in this case. Ticket is http://golang.org/issue/11745
Thanks, Tarmigan |