61–70 of 137 posts
Wow, github doesn't handle big diffs well. Some sort of automatic pagination would really help.
I would make the case the "big" diffs are a problem. Unless there's a really good reason (and bad dependency management is not a good reason) then commits should be smaller and more logically related.
Wow, github doesn't handle big diffs well. Some sort of automatic pagination would really help.
I would make the case the "big" diffs are a problem. Unless there's a really good reason (and bad dependency management is not a good reason) then commits should be smaller and more logically related.
So what is the bootstrap process going to be? Other than already have a Go compiler I mean. Or is it have a Go cross compiler? Maybe it matters less, you used to always assume bootstrap from C but that more or less died with C++ based compilers, although you can do a multistage bootstrap from the last gcc before C++ still.
It is explained in the design document: https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdw... Basically, you start from the last C version, and every version is supposed to be able to compile the next one.
One does wonder if the register re-naming from their abstract (but misleading) names to their proper machine names (e.g., from "SP" to "R13") wasn't at all a reaction to the (in)famous polemic on the golang build chain.[1] [1] http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/
I'm a little surprised you brought that post up to begin with. It completely misses the point, as I explained in my comment here at the time (https://news.ycombinator.com/item?id=8817990). When I wrote that response I also submitted a comment on the blog itself with a link to the HN comment. That blog comment has not yet been published. If you're going to keep sending around links to such an inflammatory blog post, could you also try to get my comment there approved?
Thanks.
Wow, github doesn't handle big diffs well. Some sort of automatic pagination would really help.
I would make the case the "big" diffs are a problem. Unless there's a really good reason (and bad dependency management is not a good reason) then commits should be smaller and more logically related.
Earlier quoted context omitted.
It is explained in the design document: https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdw... Basically, you start from the last C version, and every version is supposed to be able to compile the next one.
So if you want to avoid trusting trust, you need to audit not only a C compiler and the source code for the Go compiler you plan on using, but also every past Go compiler as well?
Wow, github doesn't handle big diffs well. Some sort of automatic pagination would really help.
I would make the case the "big" diffs are a problem. Unless there's a really good reason (and bad dependency management is not a good reason) then commits should be smaller and more logically related.
So what is the bootstrap process going to be? Other than already have a Go compiler I mean. Or is it have a Go cross compiler? Maybe it matters less, you used to always assume bootstrap from C but that more or less died with C++ based compilers, although you can do a multistage bootstrap from the last gcc before C++ still.
Earlier quoted context omitted.
Ah ok, so there will be a pretty long chain from 1.2 eventually, but hopefully it will be part of the test suite...
You should always be able to build a Go 1.x compiler with just the 1.4 tool chain binaries. We have committed to sticking to the Go 1.4 language and libraries for the compiler tool chain.